Hi Georges, Quoting Georges Khaznadar (2022-06-10 17:58:36) > 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.
at boot time? That's odd. Isn't the user created as part of a maintainer script? > Is there a rationale to reserve a global static id for crontab? Is the value > 101 precisely important for the the crontab group? The rationale would be uniformity and reproducibility. If the crontab group was statically allocated to id X, then it would not matter which tool was used to create a chroot nor would it matter in which order apt decided to install packages. Reproducibly creating the bit-by-bit identical output might seem like a weak argument to some, but knowing that some bits are always the same and are not randomly different makes things like tracking down bugs and regressions much easier and helps to make sure that the chroot I'm building is exactly what I expect it to be. This again is also a security argument: distributions like tails or distributors of system images will want to give the user the tools to rebuild their stuff and let them see that the stuff the user builds is the same stuff that they distribute -- this makes it harder for malicious third parties to temper with system images as there can always be third parties that verify that nothing was tempered with. > 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. Then maybe I misunderstood something. /usr/bin/crontab has the suid bit set for the group permissions and is owned by the crontab group: $ ls -ld /usr/bin/crontab -rwxr-sr-x 1 root crontab 43568 Feb 22 2021 /usr/bin/crontab Does this not mean that members of the crontab group can run the crontab binary and thus gain the privileges necessary to edit their 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? Excellent question! So in general, it would be great if there was a declarative way to allocate user and group ids at installation time, so that different installation ordering by apt would not lead to different user and group ids. Alas, we do not have such a mechanism and talking with developers of apt and dpkg revealed no easy way to create it. If it existed, then yes, I would also advocate for systemd using it just as apt and cron should to create their users and groups. In that sense, no, I do not consider crontab to be of a different importance compared to systemd. But we do not have such a mechanism and thus I'm looking at the next best way to achieve reproducible uids and gids. That mechanism is statically allocating a group-id by base-passwd. Why do I approach you and not systemd? Two reasons: - cron was first released in 1975, it is ancient old software and thus well established, stable and enjoys wide usage on all platforms -- in contrast to systemd which is young - I think because cron literally survived nearly half a century it is fair to assume it will stay with us for quite a bit longer and adding it to the special group of gids will not be unnatural -- I'm not asking to add a tool that was written just last year - if we have a static gid for cron, then it will not matter anymore that systemd is not statically allocated in practice because it will just grab the next free gids which at that point will be deterministic and not depend on installation order So yes, due to its age and prevalence I *do* consider cron to be more special than systemd. I don't know what our next init system will be and maybe we will stick around with systemd for a while but after 47 years of cron, I think would not be strange to ask for special treatment. Thanks! cheers, josch
signature.asc
Description: signature
