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 : > Hi Colin, > > thank you for your quick reply! > > Quoting Colin Watson (2022-06-13 12:27:59) > > On Mon, Jun 13, 2022 at 11:27:07AM +0200, Georges Khaznadar wrote: > > > 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. > > > > 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. > > > > > > 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. > > > > 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. > > 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-d...@lists.debian.org to the CC. > > 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
