Hi, I reassigned bug #1012622 to base-passwd, in order to make constant the group id for crontab. I believe that the arguments provided by Johannes Schauer Marin Rodrigues are strong enough to propose a change.
What led to that situation: I discussed with Christian Kastner about the package cron, which is now a distant fork of the upstream package known as "vixie cron". The gap is so wide currently that it becomes difficult to try synchronizing debian's cron with the last version of "vixie cron", which appears as dead nowadays. In order to prepare the future, I agreed with Christian that we should rebase debian's cron on the upstream package cronie, which is actively maintained by the Fedora community. Such a transition must be done very carefully, as cron is a package very close to the trunk of every debian system. The first step is to split the former package cron into two distinct packages: "cron-daemon-common" and "cron", the first one providing commons data files, the second one providing programs. So we will be able to have the package cronie depend on cron-daemon-common, and provide the feature "cron". As a side effet, the split of former cron into cron-daemon-common and cron packages reorders the package configuration, and the gid for the group crontab is no longer reproducible. Please find attached the patch which provides a constant id (= 101) for crontab. 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
diff --git a/debian/changelog b/debian/changelog
index f386cd9..645393b 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -28,6 +28,12 @@ base-passwd (3.6.0) UNRELEASED; urgency=medium
* Make it possible to build without debconf support or documentation
generation.
+ [ Georges Khaznadar ]
+ * frozen the group id for crontab (= 101), in order to have this id
+ reproducible, whether one builds a system with debootstrap or with
+ mmdebstrap. (closes: #1012622)
+
+
-- Colin Watson <cjwat...@debian.org> Mon, 04 Oct 2021 19:20:11 +0100
base-passwd (3.5.52) unstable; urgency=medium
diff --git a/group.master b/group.master
index 3e7bf1c..8ee9dd7 100644
--- a/group.master
+++ b/group.master
@@ -35,4 +35,5 @@ plugdev:*:46:
staff:*:50:
games:*:60:
users:*:100:
+crontab:*:101:
nogroup:*:65534:
signature.asc
Description: PGP signature
