Bug#411059: sash: bad practice of multiple accounts with uid==0 lead to broken system
On 2024-04-05 21:59, Michael Tokarev wrote: > Control: title -1 nscd caches "wrong" name for accounts with the same uid > Control: found -1 2.37-15 > > Rehashing this 17-years old bug which biten me today quite hard. > > On Mon, 12 Feb 2007 22:55:28 -0500 Yaroslav Halchenko > wrote: > > > > Today, after unsucsessful attempt to login as sashroot, I've got somewhat > > broken system -- all processes running under uid=0 were reported > > belonging to sashroot. Due to lack of knowledge of nss internals I > > inquired on -devel mailing list and it seems that multiple accounts > > sharing uid=0 might be considered a bad practice. For more details see > > http://lists.debian.org/debian-devel/2007/02/msg00323.html > > thread. > > > > If you can prove that it is 'documented feature of nss' to resolve in > > some deterministic way a uid whenever multiple ones are possible, then > > probably this bug has to be reassigned against libc6 to which > > libnss_files belongs. > > > > Since this bug might drive whole system broken, I am assigning it > > important priority, since a big proportion of sash users probably use > > sashroot account feature. > > The problem here is that nscd caches both username and uid on each > lookup, instead of caching just the lookup which has been asked, > and doing the other lookup the normal way as would be done by > getpwnam/getpwuid (and similar for getgrnam/getgrgid etc). > > For very long time we relied on multiple special accounts having > the same uid, exactly like this very sashroot case. We had this > for a few system/special accounts. Each name has its own password > and/or ssh keys (when in use), and each does start/manage its > subsystem with the right permissions. > > Now, with normal getpwuid(), it will return the first entry with > the given uid. But in case of nscd, it returns last looked up > entry with this uid instead. Eg, we have root and r_mjt, - > when I run getpwnam(root), getpwuid(0) will return the same > entry. But once I looked up getpwname(r_mjt), getpwuid(0) > will return r_mjt instead of root from now on. > > Here's another incarnation of the very same theme: > > https://run.tournament.org.il/multiple-users-with-the-same-uid-gid/ > > I guess they use oracle rdbms, and for this one it is also very > helpful to have 2-3 accounts with the same uid, for managing > purposes. And it breaks badly with nscd too. > > Why this bug is marked 'wontfix'? Having multiple users with the same uid in not something supported, and therefore you just encountered an undefined behaviour. Please see this message which tagged the bug as wontfix: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=411059;msg=15 That said, please feel free to work with upstream to provide a patch. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Processed (with 1 error): Re: Bug#411059: sash: bad practice of multiple accounts with uid==0 lead to broken system
Processing control commands: > title -1 nscd caches "wrong" name for accounts with the same uid Unknown command or malformed arguments to command. > found -1 2.37-15 Bug #411059 [nscd] nscd: getpwuid() behavior differs from default (de-facto standard) Marked as found in versions glibc/2.37-15. -- 411059: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=411059 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#411059: sash: bad practice of multiple accounts with uid==0 lead to broken system
Control: title -1 nscd caches "wrong" name for accounts with the same uid Control: found -1 2.37-15 Rehashing this 17-years old bug which biten me today quite hard. On Mon, 12 Feb 2007 22:55:28 -0500 Yaroslav Halchenko wrote: Today, after unsucsessful attempt to login as sashroot, I've got somewhat broken system -- all processes running under uid=0 were reported belonging to sashroot. Due to lack of knowledge of nss internals I inquired on -devel mailing list and it seems that multiple accounts sharing uid=0 might be considered a bad practice. For more details see http://lists.debian.org/debian-devel/2007/02/msg00323.html thread. If you can prove that it is 'documented feature of nss' to resolve in some deterministic way a uid whenever multiple ones are possible, then probably this bug has to be reassigned against libc6 to which libnss_files belongs. Since this bug might drive whole system broken, I am assigning it important priority, since a big proportion of sash users probably use sashroot account feature. The problem here is that nscd caches both username and uid on each lookup, instead of caching just the lookup which has been asked, and doing the other lookup the normal way as would be done by getpwnam/getpwuid (and similar for getgrnam/getgrgid etc). For very long time we relied on multiple special accounts having the same uid, exactly like this very sashroot case. We had this for a few system/special accounts. Each name has its own password and/or ssh keys (when in use), and each does start/manage its subsystem with the right permissions. Now, with normal getpwuid(), it will return the first entry with the given uid. But in case of nscd, it returns last looked up entry with this uid instead. Eg, we have root and r_mjt, - when I run getpwnam(root), getpwuid(0) will return the same entry. But once I looked up getpwname(r_mjt), getpwuid(0) will return r_mjt instead of root from now on. Here's another incarnation of the very same theme: https://run.tournament.org.il/multiple-users-with-the-same-uid-gid/ I guess they use oracle rdbms, and for this one it is also very helpful to have 2-3 accounts with the same uid, for managing purposes. And it breaks badly with nscd too. Why this bug is marked 'wontfix'? Thanks, /mjt
