Re: UID mismatch across systems

[Ross Boylan]

I made some discoveries on a test system:

root@IDTest:/etc# date; usermod -u 204 Debian-exim
Tue Mar 28 15:01:19 PDT 2017
usermod: user Debian-exim is currently used by process 664

and this left everything, including the running process and passwd untouched.

So I don't have to worry about what happens when I usermod the id when
a process is running; usermod won't do that.  Of course I can still
edit the passwd file by hand, but by itself I assume this will leave
the uid of existing processes and files unchanged (except they will
display differently in ls or ps).

Also, after I stopped exim4 and executed the usermod command above,
only the passwd file changed.  So that's easy enough to do offline.

As documented, usermod changes the uids of files in the user home
directory and below, but leaves others untouched:
root@IDTest:/etc# find / -uid 104 -ls
find: `/proc/5056/task/5056/fd/5': No such file or directory
find: `/proc/5056/task/5056/fdinfo/5': No such file or directory
find: `/proc/5056/fd/5': No such file or directory
find: `/proc/5056/fdinfo/5': No such file or directory
1317644 drwxr-s---   2 104  adm  4096 Mar 28 12:52
/var/log/exim4
1314864 -rw-r-   1 104  adm   756 Mar 28 14:56
/var/log/exim4/mainlog
 109430 drwxr-x---   2 104  Debian-exim   40 Mar 28 15:03 /run/exim4
root@IDTest:/etc# find / -uid 204 -ls
find: `/proc/5057/task/5057/fd/5': No such file or directory
find: `/proc/5057/task/5057/fdinfo/5': No such file or directory
find: `/proc/5057/fd/5': No such file or directory
find: `/proc/5057/fdinfo/5': No such file or directory
1317664 drwxr-x---   5 Debian-exim Debian-exim 4096 Mar 28
12:50 /var/spool/exim4
1317684 drwxr-x---   2 Debian-exim Debian-exim 4096 Mar 28
12:50 /var/spool/exim4/input
1317694 drwxr-x---   2 Debian-exim Debian-exim 4096 Mar 28
12:50 /var/spool/exim4/msglog
1317674 drwxr-x---   2 Debian-exim Debian-exim 4096 Mar 28
12:50 /var/spool/exim4/db

Ross

Re: UID mismatch across systems

[Joshua Schaeffer]

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

Re: UID mismatch across systems

[Ross Boylan]

On Sun, Mar 26, 2017 at 2:47 PM, Joshua Schaeffer
 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

Re: UID mismatch across systems

[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 directories.

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 
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 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).

Thanks,
Joshua Schaeffer

Re: UID mismatch across systems

[deloptes]

Ross Boylan wrote:

> To solicit advice about how to deal with the mismatch, including the
> options I mentioned originally:
> 1) manually change the uids/gids  so  they match--and how to do that
> safely, esp on a live system
> 2) live with the the mismatches, at least for system accounts.
> 
> I was also wondering how systems could be set up to have matching ids,
> given that the initial install doesn't use a shared identity database.
> For example, my newer systems have uid 101 = input, while pre-jessie
> ones have 101 = libuuid.  The new ones have systemd-* users at
> 102-105, while the older ones have other users there.
>>
>> There is no magic wand for that - debian has default numbering for system
>> accounts, so only user and custom accounts need to be moved to some user
>> management system like mysql or ldap. Of course OP will need to chown on
>> each machine to make it work.
> 
> I am the OP!  Thanks  for your responses.

Ah, sorry I did not notice you are the OP.
I was once told debian uses same uid/gid for the system accounts, but it
looks like it is not true. However I am sure there is somewhere
documentation/discussion about this.

In general you don't mess up with the system accounts.
Only your user accounts would be managed in LDAP (or MySQL). This is what
you want. So answer to your 1) is yes only for user accounts and this would
imply 2) as yes unless you have some good reason to manage system accounts
via  LDAP (or MySQL), but I have never heard of such.
The tricky part here is if users are in some system groups and they differ
between hosts. In this case you could distribute same passwd/group and
shadow files to all machines and need to update (chown) all related
files/dirs same as step 5.

you need to
1. create a list of all users on each host and uid/gid on that host. 
2. assign a unique uid/gid to each user
3. create/migrate the users to LDAP (or MySQL) to those uid/gid
4. update each host to use LDAP (or MySQL) as pam service
5. chown all files/dirs belonging to each of the user (I think find is good
at that
6. remove the local users (but leave one user account for admin tasks)

There are some good docs around about how this is done.

I hope that helps

regards

Re: UID mismatch across systems

[Ross Boylan]

On Sun, Mar 26, 2017 at 11:21 AM, deloptes  wrote:
> Ross Boylan wrote:
>
>> The problem is that none of those will work if the existing uids/gids
>> on the systems are not already consistent, and they aren't.
>
> And the goal of your statement was what exactly?

To solicit advice about how to deal with the mismatch, including the
options I mentioned originally:
1) manually change the uids/gids  so  they match--and how to do that
safely, esp on a live system
2) live with the the mismatches, at least for system accounts.

I was also wondering how systems could be set up to have matching ids,
given that the initial install doesn't use a shared identity database.
For example, my newer systems have uid 101 = input, while pre-jessie
ones have 101 = libuuid.  The new ones have systemd-* users at
102-105, while the older ones have other users there.
>
> There is no magic wand for that - debian has default numbering for system
> accounts, so only user and custom accounts need to be moved to some user
> management system like mysql or ldap. Of course OP will need to chown on
> each machine to make it work.

I am the OP!  Thanks  for your responses.
Ross

Re: UID mismatch across systems

[deloptes]

Ross Boylan wrote:

> The problem is that none of those will work if the existing uids/gids
> on the systems are not already consistent, and they aren't.

And the goal of your statement was what exactly?

There is no magic wand for that - debian has default numbering for system
accounts, so only user and custom accounts need to be moved to some user
management system like mysql or ldap. Of course OP will need to chown on
each machine to make it work.

regards

Re: UID mismatch across systems

[Ross Boylan]

The problem is that none of those will work if the existing uids/gids
on the systems are not already consistent, and they aren't.

Ross

On Sun, Mar 26, 2017 at 1:57 AM, deloptes  wrote:
> Boylan, Ross wrote:
>
>> What can I do about this?
>
> I had samequestion at one point of time.
> There are perhaps at least two ways solving this.
>
> 1. use LDAP - this is more complicated but also more professional
> 2. use Mysql PAM plugin
> 3. distribute passwd and group files to slave machines
>
> https://dev.mysql.com/doc/refman/5.5/en/pam-authentication-plugin.html
> https://wiki.debian.org/LDAP/PAM
>
>

Re: UID mismatch across systems

[deloptes]

Boylan, Ross wrote:

> What can I do about this?

I had samequestion at one point of time.
There are perhaps at least two ways solving this.

1. use LDAP - this is more complicated but also more professional
2. use Mysql PAM plugin
3. distribute passwd and group files to slave machines

https://dev.mysql.com/doc/refman/5.5/en/pam-authentication-plugin.html
https://wiki.debian.org/LDAP/PAM