Your message dated Mon, 24 Jun 2024 18:34:18 +0200
with message-id <ZnmgCrZDfVI3a7fs@per>
and subject line Re: Bug#990350: [Pkg-shadow-devel] Bug#990350: shadow:
spurious subuid/subgid entries
has caused the Debian Bug report #990350,
regarding shadow: spurious subuid/subgid entries
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
990350: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990350
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Source: shadow
Version: 1:4.8.1-1
Severity: normal
Hey there.
I've recently noted that some of my systems had entries like
$ cat /etc/subuid
debian-security-support:100000:65536
lightdm:427680:65536
_apt:493216:65536
$ cat /etc/subgid
debian-security-support:100000:65536
lightdm:427680:65536
_apt:493216:65536
While in a freshly debootstrapped chroot, with the same packages installed
there is neither of these entries.
I tried to find out whther these packages themselves ever manually added
the entries, but it doesn't seem so, the just call adduesr.
After a while of trying I've noted - and this is the main reason for this
(possible) bug - that entries are created for normal users, but not for
system users.
No sure if this is by accident - if not, it should perhaps at least documented
in the manpage.
It's still a bit strange though, that I see exactly those entries from
above in my files, cause when I look at my passwd it has:
...
dnsmasq:x:120:65534:dnsmasq,,,:/var/lib/misc:/usr/sbin/nologin
dcmtk:x:122:139::/var/lib/dcmtk/db:/bin/sh
debian-security-support:x:123:140:Debian security support
check,,,:/var/lib/debian-security-support:/bin/false
uuidd:x:100:102::/run/uuidd:/usr/sbin/nologin
lightdm:x:128:146:Light Display Manager:/var/lib/lightdm:/bin/false
_apt:x:129:65534::/nonexistent:/usr/sbin/nologin
libvirt-qemu:x:64055:127:Libvirt Qemu,,,:/var/lib/libvirt:/usr/sbin/nologin
...
Now let's assume the behaviour of adding subuid/subgid entries started some
time after my dcmtk was created... and ended for system users some time
before libvirt-qemu was created...
then it still doesn't explain why uuidd, which was chronologically likely in
between, didn't get one.
Cheers,
Chris.
PS: Is there recommended way to add the subuid/subgid entries for all those
users/groups that were created before this was introduced and which would
get them, were they created now?
--- End Message ---
--- Begin Message ---
On Sat, Jun 26, 2021 at 08:29:37PM +0200, Christoph Anton Mitterer wrote:
> > The fact that it doesn't happen for system users is not clearly
> > spelled
> > out, you're right.
>
> So that is in fact desired?!
It's been like that since the first version that supported it:
useradd -r prevents subid allocation.
Additionally, subids are only allocated if the files in /etc already
exist when the user is created.
I think this is fine.
Why your old systems have subid allocations for *some* "system"
users is still unclear, but maybe the users were not considered
"system" when they were created.
However in *current* shadow, I think everything works as it should.
Chris
--- End Message ---
_______________________________________________
Pkg-shadow-devel mailing list
[email protected]
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-shadow-devel
