Re: UID mismatch across systems
On Sun, Mar 26, 2017 at 2:47 PM, Joshua Schaeffer
<jschaeffer0922@gmail.com> wrote:
>
> 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
> directories.
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
issue.
>
> 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.
Ross
Reply to: