Re: UID mismatch across systems
On Sun, Mar 26, 2017 at 2:47 PM, Joshua Schaeffer
> On 03/25/2017 03:03 PM, Boylan, Ross wrote:
> The problem is that I can't convert to using a shared directory when
> different systems assign different uids to the same named user. In other
> words, to get to the shared accounts solution I must already have solved the
> problem of mismatching ids.
> Not entirely true, NFSv4 has the ability to map uid/gid between systems with
> the rpc.idmapd program, which uses the idmapd.conf configuration files.
> The problems are mostly with system users, and I've seen some advice
> indicating such users don't normally go in LDAP. So excluding would reduce
> the problem, for LDAP, but also leave lots of unsynchronized ids.
> What is the issue of unsynchronized system ids? Are you allowing login of
> these system ids? Are they also sharing a filesystem (NFS, CIFS, etc) for
> these system ids? My assumption is that when you say shared directory you
> are talking about $HOME for a normal user. If that's not the case then it
> sounds like you are using an old technique where many systems mount shared
> filesystems to /usr, /usr/share, /opt, etc. I haven't seen that in years as
> disks are quite large enough to handle the space needed for these
The main practical problem is with backups, restores and copies that
use numeric ids instead of names. This includes taking a disk that
was used on one system and using it in another.
Beyond that, I had a general sense that the mismatched ids could cause
trouble. You're right, I'm not likely to be doing things like ssh'ing
after having assumed a system account id or sharing files owned by
system ids over NFS. So it may be just the backup/copying that's an
> I'm not sure how much a problem it the mismatches are for NFSv4; I believe
> it allows user/kerberos based authentication, but I'm not sure what that
> means for the uids of the files.
> Mismatched ids in NFSv4 will result in a uid/gid of -1, which translates to
> something like 4294967295 (I don't think that's the exact number but it's
> close to 2^32) when you run an ls -l on the NFS mount point.
> LDAP is my go to solution for synchronized authorization and central account
> management (I do not use it for authentication, but that is my own personal
I was planning on using kerberos. Partly that's because I thought
NFSv4 needed it anyway.
> preference). I advocate it, but I know some people prefer simpler solutions
> depending on the situation. A company of 10 systems can easily avoid all of
> the management, hardware, upkeep, etc of LDAP and use something like NIS,
> Puppet, etc or use no central management at all.
> I guess I'm not understanding the core problem. I never put system ids
> (including root) into LDAP, only user's ids. Typing this out, it occurred to
> me that I am assuming you mean a system id is an id of >1000 (in Debian). If
I mean ids < 1000. 1000+ seems to be for users on my systems. On my
systems it's 100-124 that have the problems.
> you are talking about some generic account that is not an actual system ID,
> but is not used by a specific user, then yes you have to find a way to
> synchronize and/or transfer the account. I would simply create the account
> in LDAP and then transfer all ownership of processes and files to that new
> account (as you already stated).
Are you saying there is a way to change the uid/gid of a process that
is already running from the outside? Does usermod do that if you
change the uid?
My concern is that if I change file uids existing processes will gag
and, worst case, the system becomes non-functional even on reboot.*
This seems particularly acute with systemd. I know I can shutdown
most services, change ids, and restart them. But I have the
impression that the ones associated with systemd, and maybe some
others like messagebus, are essential and have to be left running.
And I am accessing the systems via ssh, and so changing the ssh u/gid
seems especially dicey.
*It just occurred to me I could temporarily make permissions more
permissive, or add group permissions, to avoid getting locked out.