1 |
On Sun, Nov 28, 2021 at 02:46:24PM -0600, William Hubbs wrote: |
2 |
> On Sun, Nov 28, 2021 at 08:15:13PM +0100, Michał Górny wrote: |
3 |
> > On Sun, 2021-11-28 at 13:06 -0600, William Hubbs wrote: |
4 |
> > > On Sun, Nov 28, 2021 at 11:06:36AM +0100, Ulrich Mueller wrote: |
5 |
> > > > > > > > > On Sun, 28 Nov 2021, William Hubbs wrote: |
6 |
> > > > |
7 |
> > > > > On Mon, Nov 15, 2021 at 09:36:32AM +0300, Eray Aslan wrote: |
8 |
> > > > > > 1/ Static allocation does not really solve a problem. Not really not |
9 |
> > > > > > nowadays |
10 |
> > > > > > 2/ We cant keep adding new IDs to a distribution as new software gets |
11 |
> > > > > > added - one side is unbounded. This is losing game. |
12 |
> > > > |
13 |
> > > > Not sure. In practice, the number of packages is limited. (And if the |
14 |
> > > > argument was valid, it would apply to dynamic alloction too.) |
15 |
> > > > |
16 |
> > > > > > Switching back to dynamic allocation seems to be the best option. |
17 |
> > > > |
18 |
> > > > > I realize I'm very late to this party, but +1 from me also. |
19 |
> > > > |
20 |
> > > > > We should use dynamic uid/git assignment by default and maybe provide |
21 |
> > > > > a way to force certain uids/gids to be constant if users want this. |
22 |
> > > > |
23 |
> > > > While the rationale for static allocation that made it into GLEP 81 [1] |
24 |
> > > > is rather weak, several people had argued in favour of it on the mailing |
25 |
> > > > list [2]. |
26 |
> > > > |
27 |
> > > > In any case, let's cross that bridge when we reach it. For now, we're |
28 |
> > > > good with 250 additional IDs. |
29 |
> > > |
30 |
> > > It is inevitable that we will reach this bridge again -- whether or not |
31 |
> > > it is in a month or a year, it will happen. |
32 |
> > > |
33 |
> > > Why are we just kicking the can down the road instead of admitting that |
34 |
> > > static allocation wasn't a good idea and going back to dynamic |
35 |
> > > allocation? Let's find out what the people who argued for static |
36 |
> > > allocation think. |
37 |
> > > |
38 |
> > |
39 |
> > Why are you assuming that something "wasn't a good idea" just because |
40 |
> > you think so? |
41 |
> |
42 |
> ulm and others on the thread also mentioned the possibility of going |
43 |
> back to dynamic allocation, so it isn't just me who brought it up. |
44 |
> |
45 |
> I honestly am just looking for a discussion. |
46 |
> |
47 |
> Do other distros statically allocate all of their system users? If not, |
48 |
> why do we by default? I understand why enterprise users might need to, |
49 |
> and they can with the glep 81 eclasses by setting uids/gids in |
50 |
> make.conf, but is there a reason we force the issue at the distro level |
51 |
> and ban -1 as the setting for ACCT_USER_ID and ACCT_GROUP_ID? |
52 |
> |
53 |
> William |
54 |
> |
55 |
|
56 |
|
57 |
Ok, based on floppym's response, I'm going to start a new thread. |
58 |
|
59 |
William |