Allow for stateless users and groups in GuixSD

  • Done
  • quality assurance status badge
Details
5 participants
  • Alex Sassmannshausen
  • Andreas Enge
  • Thompson, David
  • Ludovic Courtès
  • Mark H Weaver
Owner
unassigned
Submitted by
Thompson, David
Severity
normal

Debbugs page

Thompson, David wrote 10 years ago
(address . bug-guix@gnu.org)
CAJ=RwfZwBVWfSOe_aMbBChFQ1YkF0xKPdhNehqnXfWEYEZFFng@mail.gmail.com
Currently, removing a user account from the users list in an OS config
does not remove the user account from a system when 'guix system
reconfigure' is run. I think that user accounts not specified in the
user accounts list should be invalidated and that /etc/passwd and
other files be fully rebuilt each time. In other words, I want a
stateless /etc/passwd, not a stateful one.

As Mark brought up on IRC, this proposed change in behavior may very
well surprise and frustrate another subset of users, so perhaps the
existing behavior should be preserved, with a bit that can be flipped
for stateless user accounts.

Thoughts?
Alex Sassmannshausen wrote 10 years ago
(name . Thompson, David)(address . dthompson2@worcester.edu)(address . 19795@debbugs.gnu.org)
874mqzar3y.fsf@yamato.home
Hello,

My 2c:

In short +1!

Thompson, David writes:

Toggle quote (7 lines)
> Currently, removing a user account from the users list in an OS config
> does not remove the user account from a system when 'guix system
> reconfigure' is run. I think that user accounts not specified in the
> user accounts list should be invalidated and that /etc/passwd and
> other files be fully rebuilt each time. In other words, I want a
> stateless /etc/passwd, not a stateful one.

I would love this functionality: it feels intuitive for a functional
package manager.

Toggle quote (5 lines)
> As Mark brought up on IRC, this proposed change in behavior may very
> well surprise and frustrate another subset of users, so perhaps the
> existing behavior should be preserved, with a bit that can be flipped
> for stateless user accounts.

I agree that perhaps statefulness should be the default for now, as that
seems the "common way to do things".

Alex
Andreas Enge wrote 10 years ago
(name . Thompson, David)(address . dthompson2@worcester.edu)(address . 19795@debbugs.gnu.org)
20150207091023.GA12524@debian
Hello,

I agree, it is rather surprising that removing a user does not remove it.
So I think it should be fully stateless (as long as the user's home
directory is not erased, of course; so this should remain as a state and
be reactivated once the user is available again, which could cause problems
with user names vs. numbers).

Andreas
Mark H Weaver wrote 10 years ago
(name . Andreas Enge)(address . andreas@enge.fr)
87iofd14og.fsf@netris.org
Andreas Enge <andreas@enge.fr> writes:

Toggle quote (6 lines)
> I agree, it is rather surprising that removing a user does not remove it.
> So I think it should be fully stateless (as long as the user's home
> directory is not erased, of course; so this should remain as a state and
> be reactivated once the user is available again, which could cause problems
> with user names vs. numbers).

If we do this, I think we should take steps to prevent users+groups from
being added, removed, group memberships changed, setting of passwords,
etc, outside of 'guix system reconfigure'. I think that users will be
very unhappy with us if commands like 'passwd' and 'useradd' work as
expected, but are undone the next time they update their system.

My position is that we should support both stateful or stateless
operation for some aspects of our configuration.

For example, consider wireless network configuration. Most casual users
want this to be stateful. They will want to be able to use a nice GUI
applet to connect to a wireless network, and have the system remember
the authentication info and to connect to that network automatically in
the future, etc. I don't want GuixSD to forget that information the
next time I update, or if I roll-back, etc.

However, for some applications it may be preferable to have the wireless
configuration completely stateless and specified in the OS config,
e.g. for a headless server that's connected via wireless.

I think it's the same way with users+groups. For my personal system, I
might want to be able to add a user without updating its software at the
same time (which might involve a lot of downloading and/or compiling),
and I don't want the new user to be erased if I roll-back.

Even for many kinds of servers, I don't think it makes sense to tie the
users+groups to the system configuration. Most of the time I don't want
that. But for some other kinds of servers, I think I would want it.

So, I think we should support both modes.

My two cents...

Mark
Ludovic Courtès wrote 10 years ago
(name . Mark H Weaver)(address . mhw@netris.org)
87egq0scbv.fsf@gnu.org
Mark H Weaver <mhw@netris.org> skribis:

Toggle quote (6 lines)
> If we do this, I think we should take steps to prevent users+groups from
> being added, removed, group memberships changed, setting of passwords,
> etc, outside of 'guix system reconfigure'. I think that users will be
> very unhappy with us if commands like 'passwd' and 'useradd' work as
> expected, but are undone the next time they update their system.

Just to be clear about the current situation: everything is stateless,
with the exception of passwords (‘reconfigure’ does not alter them) and
user accounts that are not removed (the crux of this report.)

Apart from passwords, any modification is undoed on the next
‘reconfigure’ or on the next reboot. See notably e2b464b7, which took a
step to ensure that user account settings in the OS declaration are
fully honored.

In response to this bug report, I would just add activation code that
removes any unknown user accounts.

Thanks,
Ludo’.
Ludovic Courtès wrote 10 years ago
(name . Mark H Weaver)(address . mhw@netris.org)
87pp7etngi.fsf@gnu.org
ludo@gnu.org (Ludovic Courtès) skribis:

Toggle quote (3 lines)
> In response to this bug report, I would just add activation code that
> removes any unknown user accounts.

Commit 9bea87a does that.

Let me know if it wipes all your user accounts or anything! :-)

(Seriously though, I’ve run it on my machine and everything is fine.)

Ludo’.
Closed
?
Your comment

This issue is archived.

To comment on this conversation send an email to 19795@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 19795
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch
You may also tag this issue. See list of standard tags. For example, to set the confirmed and easy tags
mumi command -t +confirmed -t +easy
Or, remove the moreinfo tag and set the help tag
mumi command -t -moreinfo -t +help