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
