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?