Dear Josch, as I am new to this kind of reasoning, please enlighten me.
So far, the package base-passwd is maintaining standard ids for: root, daemon, bin, sys, sync, games, man, lp, mail, news, uucp, proxy, majordom, postgres, www-data, backup, operator, list, irc, gnats, nobody, nogroup, messagebus, postfix, gdm, saned, klog, syslog, adm, tty, disk, kmem, dialout, dip, fax, voice, cdrom, floppy, tape, sudo, audio, src, shadow, utmp, video, plugdev, staff, users, lpadmin, sasl, scanner, ssh, sshd, fetchmail, cupsys The group id 101 for crontab used to be assessed as a consequence of pseudo-aleatory processes which happen at boot time, so far in the same order for most use cases. Is there a rationale to reserve a global static id for crontab? Is the value 101 precisely important for the the crontab group? Here are some parts of the filesystem where the group crontab is in use: --------------------8<------------------------------------------------- $ sudo find /var -group crontab | sudo xargs ls -ld drwx-wx--T 2 root crontab 4096 2 juin 18:33 /var/spool/cron/crontabs -rw------- 1 georgesk crontab 1199 27 avril 14:37 /var/spool/cron/crontabs/georgesk -rw------- 1 root crontab 1292 3 mars 17:31 /var/spool/cron/crontabs/root --------------------8<------------------------------------------------- With the standard settings, members of the crontab group can neither read nor write to individual crontabs. As a consequence, the arguments to add crontab to the list of reservations are rather weak; should the group crontab be considered as more "special" than the group systemd-journal? Should the group systemd-journal deserve also a reserved global gid? Thank you in advance for your feedback. Best regards, Georges. Johannes Schauer Marin Rodrigues a écrit : > Source: cron > Version: 3.0pl1-142 > Severity: normal > X-Debbugs-Cc: jo...@debian.org, georg...@debian.org, c...@debian.org > > Hi, > > with the introduction of the cron-daemon-common package, the group id of > the "crontab" group became unreproducible depending on how the chroot is > created, i.e. whether one uses debootstrap or mmdebstrap. Steps to > reproduce: > > $ cat > script.sh << END > #!/bin/sh > set -exu > ssh -F "$1" qemu mmdebstrap --aptopt=Acquire::Check-Valid-Until\\\ > \\\"false\\\" unstable --variant=- - $DEBIAN_BISECT_MIRROR \ > | tar --to-stdout -x ./etc/group \ > > group.mm > ssh -F "$1" qemu debootstrap unstable /tmp/debian-unstable > $DEBIAN_BISECT_MIRROR > ssh -F "$1" qemu cat /tmp/debian-unstable/etc/group > group.debootstrap > diff -u group.mm group.debootstrap > END > $ chmod +x script.sh > $ debbisect --depends=mmdebstrap,debootstrap,cron --qemu=defaults \ > --cache=./cache --no-find-exact-package 20220608T153059Z > 20220608T210836Z ./script.sh > [...] > bisection finished successfully > last good timestamp: 2022-06-08 15:30:59+00:00 > first bad timestamp: 2022-06-08 21:08:36+00:00 > the following packages differ between the last good and first bad > timestamp: > cron 3.0pl1-139 -> 3.0pl1-142 > cron-daemon-common (n.a.) -> 3.0pl1-142 > iproute2 5.17.0-2 -> 5.18.0-1 > > The output of the failing diff command above with the new cron package > is: > > --- group.mm»···2022-06-10 15:38:03.473732762 +0200 > +++ group.debootstrap»··2022-06-10 15:39:13.591459985 +0200 > @@ -37,10 +37,10 @@ > games:x:60: > users:x:100: > nogroup:x:65534: > -crontab:x:101: > -systemd-journal:x:102: > -systemd-network:x:103: > -systemd-resolve:x:104: > +systemd-journal:x:101: > +systemd-network:x:102: > +systemd-resolve:x:103: > +crontab:x:104: > input:x:105: > sgx:x:106: > kvm:x:107: > > The reason is that with the new cron-daemon-common package, apt now > orders postinst scripts differently. > > I'm not proposing to undo the recent changes in src:cron. There is also > nothing that apt can do about this. Reproducible uid/gid values is still > an open problem, see #963788. > > One possible solution though is for the crontab group being assigned a > static gid by base-passwd. This is what we attempt to do for the _apt > user in #969631. > > Do you think the crontab group would be another good candidate for a > static gid by base-passwd? If yes, please reassign this bug to > base-passwd. In that case, you might also want to propose some small > text explaining why this group is useful and what members of this group > are allowed to do. Probably this is about being able to run the crontab > command? > > Maybe since cron is such an old and established utility and because it's > part of the Priority:standard set, it would be a good fit for a static > gid from base-passwd. > > Thanks! > > cheers, josch -- Georges KHAZNADAR et Jocelyne FOURNIER 22 rue des mouettes, 59240 Dunkerque France. Téléphone +33 (0)3 28 29 17 70
signature.asc
Description: PGP signature
