Re: UID mismatch across systems

[Joshua Schaeffer <jschaeffer0922@gmail.com>]

On 03/26/2017 06:27 PM, Ross Boylan wrote:

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.

Yes, I hadn't thought about backing up a system and then restoring on another system. Just a suggestion, but in the case of backups that are restored on another system you would probably not want backup the numeric ids. Rsync actually behaves like this by default and falls back to numeric ids. You have to specify the --numeric-ids flag in order for it to preserve all IDs. From rsync(1) man page:

     --numeric-ids
                  With this option rsync will transfer numeric group and user IDs rather than using user and group names and mapping them at both ends.

                  By default rsync will use the username and groupname to determine what ownership to give files. The special uid 0 and the special  group  0
                  are never mapped via user/group names even if the --numeric-ids option is not specified.

                  If  a user or group has no name on the source system or it has no match on the destination system, then the numeric ID from the source sys‐
                  tem is used instead.

Rsync also has capabilities to map users and groups with the --usermap and --groupmap options. See the man page for details of these options as well. So by default rsync may be doing what you are looking for (or at least map the ids for you so that you don't have to go through the hassle of synchronizing all your systems) by backing up the system and attempting to restore it to the correct user by name first then by ID. Of course this assumes you are using rsync. Other backup programs (and there are aplenty) may do the opposite by default.

I was planning  on using kerberos.  Partly that's because I thought
NFSv4 needed it anyway.

It is required if you use sec=krb5, krb5i, or krb5p. sec=sys doesn't do any integrity checking, authentication, or encryption and Kerberos is not required for these exports. Right now I use LDAP and Kerberos for authentication and authorization (authn/authz). Kerberos handles the authn portion and actually uses LDAP as its backend. LDAP handles authz portion. I'm also in the process of setting up my NFSv4 server with krb5p security. Let me know if you have any questions on that.

I mean ids < 1000.  1000+ seems to be for users on my systems.  On my
systems it's 100-124 that have the problems.

Sorry, typo, I did in fact mean ids less than 1000.

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

No, I was just saying to create a new account in LDAP (this would be the new synchronized account) and then just change ownership of the files owned by the old account with chown. Your concerns are valid for accounts like systemd and daemon, and unfortunately I don't have any experience with this as I don't synchronize these types of accounts.

Thanks,
Joshua Schaeffer