Hi Josch, thank you, you sent me precisely the arguments I wished to read before asking maintainers of base-passwd to make the next move. The benefits of reproducible system builds is worth a change!
Best regards, Georges. Johannes Schauer Marin Rodrigues a écrit : > 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 -- 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
