1 |
On Sun, Jan 3, 2021 at 6:42 PM Mike Gilbert <floppym@g.o> wrote: |
2 |
> |
3 |
> On Sun, Jan 3, 2021 at 8:35 PM Thomas Deutschmann <whissi@g.o> wrote: |
4 |
> > |
5 |
> > Modifying an existing user is a bad default and makes Gentoo |
6 |
> > special because it is common for system administrators to make |
7 |
> > modifications to user (i.e. putting an user into another service's |
8 |
> > group to allow that user to access service in question) and it |
9 |
> > would be unexpected to see these changes reverted during normal |
10 |
> > world upgrade (which could break services). |
11 |
> > |
12 |
> > This commit will make Gentoo behave like any other Linux distribution |
13 |
> > by respecting any user modifications by default. However, we will retain |
14 |
> > the functionality to reset system user and groups and users interested |
15 |
> > in this feature can opt-in by setting |
16 |
> > ACCT_USER_ALLOW_EXISTING_USER_TO_BE_MODIFIED to a non-zero value in |
17 |
> > their make.conf. |
18 |
> |
19 |
> So the main problem I see with doing this is that it becomes |
20 |
> impossible to reliably make changes to a user in later ebuild |
21 |
> revisions. Developers may want/need to deploy changes to user |
22 |
> attributes. Changing group memberships seems like the best example, |
23 |
> but I could foresee a want/need to change DESCRIPTION, HOME, or SHELL |
24 |
> as well. |
25 |
|
26 |
I think the TL;DR is I don't believe changes in HOME, or SHELL are |
27 |
safe to do in later revisions. This means developers: |
28 |
- Need to be careful when picking em! |
29 |
- Can use later revisions to set sane defaults for fresh installs. |
30 |
- Can't touch existing installs because changing HOME and SHELL can |
31 |
cause user-facing breakage. |
32 |
|
33 |
Often if HOME points somewhere that isn't /dev/null, you have to do |
34 |
some kind of migration. I'd rather not enable that sort of breakage by |
35 |
default because it's a per-app / per-user migration pain. |
36 |
|
37 |
To pick an example: |
38 |
|
39 |
The git user has a HOME in either /var/lib/gitea or /var/lib/gitolite. |
40 |
If you change it, you will break whatever service is running. |
41 |
This is the same for any service account whose $HOME stores |
42 |
state...which is most of them with a HOME set. |
43 |
|
44 |
-A |
45 |
|
46 |
> |
47 |
> Because of this, I think the new behavior should be opt-in, and people |
48 |
> who use it should be aware that they will need to pay attention if any |
49 |
> account changes are rolled out in new ebuild versions. |
50 |
> |
51 |
> > diff --git a/eclass/acct-user.eclass b/eclass/acct-user.eclass |
52 |
> > index 22b0038fbff7..d60b1e53b4bb 100644 |
53 |
> > --- a/eclass/acct-user.eclass |
54 |
> > +++ b/eclass/acct-user.eclass |
55 |
> > @@ -309,6 +321,20 @@ acct-user_pkg_pretend() { |
56 |
> > fi |
57 |
> > } |
58 |
> > |
59 |
> > +# @FUNCTION: acct-user_pkg_setup |
60 |
> > +# @DESCRIPTION: |
61 |
> > +# Initialize internal environment variable(s). |
62 |
> > +acct-user_pkg_setup() { |
63 |
> > + debug-print-function ${FUNCNAME} "${@}" |
64 |
> > + |
65 |
> > + # check if user already exists |
66 |
> > + ACCT_USER_ALREADY_EXISTS= |
67 |
> > + if [[ -n $(egetent passwd "${ACCT_USER_NAME}") ]]; then |
68 |
> > + ACCT_USER_ALREADY_EXISTS=yes |
69 |
> > + fi |
70 |
> > + readonly ACCT_USER_ALREADY_EXISTS |
71 |
> > +} |
72 |
> |
73 |
> I don't think this pkg_setup function is necessary; you could do this |
74 |
> in pkg_preinst instead, before enewuser gets called. |
75 |
> |