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:

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 :

Hi Georges,

Quoting Georges Khaznadar (2022-06-10 17:58:36)

at boot time? That's odd. Isn't the user created as part of a maintainer
script?
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.

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?

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

Hello,

Bug #1012622 in base-passwd reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/debian/base-passwd/-/commit/5ce77739fb387ba36f7bb75570af63aec038d963
------------------------------------------------------------------------
frozen the group id for crontab, closes: #1012622
------------------------------------------------------------------------

(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1012622

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-13 10:56:28)

I don't think this is a good solution:

https://salsa.debian.org/debian/base-passwd/-/commit/e1a186baa5cec0ee1ffed6a06344bc2a492c3e3d

I'm putting Colin as the base-passwd maintainer into CC.

Firstly, I don't think you should statically allocate group 101 like this
because that's inside the 100-999 range which is dynamically allocated:

https://www.debian.org/doc/debian-policy/ch-opersys.html#uid-and-gid-classes

Secondly, each new group should be documented. Introducing a new group probably
needs documentation in doc/users-and-groups.sgml as it is for example done
here:

https://salsa.debian.org/debian/base-passwd/-/commit/af62feef458e3787bd460a2822d402d5a970b237

Did you discuss this change with Colin? Otherwise, maybe you first want to
revert your changes to not cause any accidental damage. I think Colin needs to
have a say in to whether or not a statically allocated crontab group maintained
by base-passwd is a good idea or not.

Thanks!

cheers, josch

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 :

Hello Josch,

thank you for your very fast feedback.

You are right, I shall revert my changes, and put proposed changes
in a separate branch of the git tree, so it will be easier to
cherry-pick them.

Best regards,			Georges.

Johannes Schauer Marin Rodrigues a écrit :

Correct, I will not accept any new static allocation in that range.

I'm afraid I am not very convinced by this line of argument; it seems
very weak and circumstantial.  It leaves us in a position where every
package with a user or group that might conceivably end up owning files
in a system image will want to have a static ID, and there will be no
particularly good way to draw distinctions between which ones should and
which ones shouldn't.  The space of available static IDs is large
(60000-64999), but not infinite; I would much rather push back on this
proposal since otherwise there will be no incentive to come up with a
more reasonably-scalable approach.

The cases where I allocate static IDs at present are typically those
where it's important for interoperability that they be the same on all
systems, often situations involving networked filesystems and such.

Why would this be a matter for apt/dpkg, rather than for adduser?  Yes,
there have been various conversations about doing declarative user/group
creation in dpkg, but at present dynamic system users/groups are created
by adduser.

Couldn't we fairly easily add a configuration file that adduser would
read with preseeded user/group IDs for various names, and have it
preferentially use those IDs if available rather than picking
arbitrarily from the relevant ID namespace?  This certainly seems a lot
easier than adding declarative user/group creation to dpkg.

Hello,

Bug #1012622 in base-passwd reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/debian/base-passwd/-/commit/0145e8a72643a0cabec9689973ae10bf21111028
This reverts commit 5ce77739fb387ba36f7bb75570af63aec038d963.
------------------------------------------------------------------------

(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1012622

I'm quite unhappy by the mess that you've left in base-passwd git
master, with repeated revert-of-revert type commits *after* this message
from you; I can't really undo those properly because it would involve
rewriting history of a published branch.  Please fix your git config and
don't push to base-passwd master again!

Hi Colin,

thank you for your quick reply!

Quoting Colin Watson (2022-06-13 12:27:59)

I did not consider this way of solving this problem yet. Partly, because I'd
like to remove the adduser dependency from the apt maintainer script to create
the _apt user -- see #969631.

So you propose to introduce another registry of uid/gid <-> user/group mappings
but not maintained by the base-passwd package but by the adduser package? I
guess this should use the range 100-999, right?

Adding support for default uid/gid numbers to adduser would probably a "quick
fix" but I wonder whether this is the approach we want to use in the long term.
Since there is also https://wiki.debian.org/Teams/Dpkg/Spec/SysUser I'm adding
debian-dpkg@lists.debian.org to the CC.

Thanks!

cheers, josch

I wasn't suggesting a centrally-maintained registry; that would just
move the limited-namespace problem somewhere else.  My suggestion was
more that adduser could read a file of ID preferences, ignored if the ID
is already taken, which could be used when testing reproducibility of
images.  There should be no need for those preferences to be otherwise
consistent across systems.

Hi Colin, Josch,

just in case: I pushed my modifications again, but in a separate branch
(branch "crontab") which was forked off from master today, after
previous changes in master were reverted.

The new modifications are :
- reserved gid 47 for group crontab
- added a few lines to the documentation file.

Please feel free to tackle out the new branch if it is useless, and to
close the bug report if it is not relevant now.

Best regards,			Georges.


Johannes Schauer Marin Rodrigues a écrit :