User shell: state or config?

User shell: state or config?

[Ludovic Courtès]

[-- Attachment #1: Type: text/plain, Size: 1876 bytes --]

Hello Guix!

We recently discussed handling of the ‘shell’ field of ‘user-account’:

  https://lists.gnu.org/archive/html/help-guix/2019-04/msg00171.html

As I wrote there, starting with the switch to (gnu build accounts) in
0ae735bcc8ff7fdc89d67b492bdee9091ee19e86, user shells are considered
“state”.  Before they were “config”: ‘guix system reconfigure’ would
always reset the user shells.

Considering user shells as state seemed like a good idea because, on a
multi-user system, you’d rather let user invoke ‘chsh’ than have root
reconfigure the system just to change the user’s shell.  The patches
below document that.

However, thinking more about it, I’m not sure if considering shells as
state is such a good idea, for several reasons:

  1. It’s surprising that ‘guix system reconfigure’ doesn’t actually
     change the shell, as Tanguy reported.

  2. ‘chsh’ restricts users to the shells listed in /etc/shells anyway,
     which is the combination of all the ‘shell’ fields, currently.

     Given this restriction, you might just as well ask the admin to
     change the shell for you.

  3. It’s easy to end up with a shell that’s eventually GC’d.

     Scenario #1: your shell is initially set to
     /gnu/store/…-bash/bin/bash, which at the time is GC-protected
     (listed in /etc/shells, etc.).  However, later, this specific Bash
     variant is GC’d, and boom, you’re left with nothing.

     Scenario #2: you set your shell to
     /run/current-system/profile/bin/zsh, which is GC-protected, but
     eventually the admin removes zsh for the global profile.

All in all, I’m in favor of switching back to the previous behavior:
considering user shells as system config.  That’s a one-line change in
(gnu build accounts).

Thoughts?

Ludo’.


[-- Attachment #2: allow for chsh --]
[-- Type: text/x-patch, Size: 1846 bytes --]

From d1586f0c77cf63d0259cca9fc50c210c584529b3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ludovic=20Court=C3=A8s?= <ludo@gnu.org>
Date: Thu, 25 Apr 2019 12:10:06 +0200
Subject: [PATCH 1/2] system: Add 'chsh' to %SETUID-PROGRAMS.

* gnu/system/pam.scm (base-pam-services): Add "chsh".
* gnu/system.scm (%setuid-programs): Add chsh.
---
 gnu/system.scm     | 1 +
 gnu/system/pam.scm | 4 ++--
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/gnu/system.scm b/gnu/system.scm
index b00d384fee..a85ec109ac 100644
--- a/gnu/system.scm
+++ b/gnu/system.scm
@@ -794,6 +794,7 @@ use 'plain-file' instead~%")
   ;; Default set of setuid-root programs.
   (let ((shadow (@ (gnu packages admin) shadow)))
     (list (file-append shadow "/bin/passwd")
+          (file-append shadow "/bin/chsh")
           (file-append shadow "/bin/su")
           (file-append shadow "/bin/newuidmap")
           (file-append shadow "/bin/newgidmap")
diff --git a/gnu/system/pam.scm b/gnu/system/pam.scm
index 13f76a50ed..27239c5621 100644
--- a/gnu/system/pam.scm
+++ b/gnu/system/pam.scm
@@ -1,5 +1,5 @@
 ;;; GNU Guix --- Functional package management for GNU
-;;; Copyright © 2013, 2014, 2015, 2016, 2017 Ludovic Courtès <ludo@gnu.org>
+;;; Copyright © 2013, 2014, 2015, 2016, 2017, 2019 Ludovic Courtès <ludo@gnu.org>
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -265,7 +265,7 @@ authenticate to run COMMAND."
           ;; These programs are setuid-root.
           (map (cut unix-pam-service <>
                     #:allow-empty-passwords? allow-empty-passwords?)
-               '("passwd" "sudo"))
+               '("passwd" "chsh" "sudo"))
           ;; This is setuid-root, as well.  Allow root to run "su" without
           ;; authenticating.
           (list (unix-pam-service "su"
-- 
2.21.0


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: document --]
[-- Type: text/x-patch, Size: 1298 bytes --]

From 6ab1ecd628f13829e31e4bcbe7bf0ff53951eedd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ludovic=20Court=C3=A8s?= <ludo@gnu.org>
Date: Thu, 25 Apr 2019 12:23:11 +0200
Subject: [PATCH 2/2] doc: Document 'chsh'.

* doc/guix.texi (User Accounts): Document 'chsh'.
---
 doc/guix.texi | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/doc/guix.texi b/doc/guix.texi
index 879cb562e9..b5048f7269 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -11000,6 +11000,15 @@ if it does not exist yet.
 This is a G-expression denoting the file name of a program to be used as
 the shell (@pxref{G-Expressions}).
 
+Users may change their shell at any time by running the @command{chsh}
+command---run @command{man chsh} for more info.  The list of allowed shells
+can be found in the @file{/etc/shells} file, which is itself the combination
+of the @code{shell} fields of all the user accounts.
+
+Because the account's shell is user-modifiable system state---just like
+passwords---it is preserved across reboots and reconfiguration, even if the
+administrator changes the value of the @code{shell} field.
+
 @item @code{system?} (default: @code{#f})
 This Boolean value indicates whether the account is a ``system''
 account.  System accounts are sometimes treated specially; for instance,
-- 
2.21.0

Re: User shell: state or config?

[mikadoZero]

Ludovic Courtès writes:

> Hello Guix!
>
> We recently discussed handling of the ‘shell’ field of ‘user-account’:
>
>   https://lists.gnu.org/archive/html/help-guix/2019-04/msg00171.html
>
> As I wrote there, starting with the switch to (gnu build accounts) in
> 0ae735bcc8ff7fdc89d67b492bdee9091ee19e86, user shells are considered
> “state”.  Before they were “config”: ‘guix system reconfigure’ would
> always reset the user shells.
>
> Considering user shells as state seemed like a good idea because, on a
> multi-user system, you’d rather let user invoke ‘chsh’ than have root
> reconfigure the system just to change the user’s shell.  The patches
> below document that.
>
> However, thinking more about it, I’m not sure if considering shells as
> state is such a good idea, for several reasons:
>
>   1. It’s surprising that ‘guix system reconfigure’ doesn’t actually
>      change the shell, as Tanguy reported.

As a new user of Guix System I was recently surprised by this as well.
I was expecting the shell to be managed by configuration.

https://lists.gnu.org/archive/html/help-guix/2019-03/msg00089.html

>   2. ‘chsh’ restricts users to the shells listed in /etc/shells anyway,
>      which is the combination of all the ‘shell’ fields, currently.
>
>      Given this restriction, you might just as well ask the admin to
>      change the shell for you.
>
>   3. It’s easy to end up with a shell that’s eventually GC’d.
>
>      Scenario #1: your shell is initially set to
>      /gnu/store/…-bash/bin/bash, which at the time is GC-protected
>      (listed in /etc/shells, etc.).  However, later, this specific Bash
>      variant is GC’d, and boom, you’re left with nothing.
>
>      Scenario #2: you set your shell to
>      /run/current-system/profile/bin/zsh, which is GC-protected, but
>      eventually the admin removes zsh for the global profile.
>
> All in all, I’m in favor of switching back to the previous behavior:
> considering user shells as system config.  That’s a one-line change in
> (gnu build accounts).
>
> Thoughts?
>
> Ludo’.
>
> From d1586f0c77cf63d0259cca9fc50c210c584529b3 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Ludovic=20Court=C3=A8s?= <ludo@gnu.org>
> Date: Thu, 25 Apr 2019 12:10:06 +0200
> Subject: [PATCH 1/2] system: Add 'chsh' to %SETUID-PROGRAMS.
>
> * gnu/system/pam.scm (base-pam-services): Add "chsh".
> * gnu/system.scm (%setuid-programs): Add chsh.
> ---
>  gnu/system.scm     | 1 +
>  gnu/system/pam.scm | 4 ++--
>  2 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/gnu/system.scm b/gnu/system.scm
> index b00d384fee..a85ec109ac 100644
> --- a/gnu/system.scm
> +++ b/gnu/system.scm
> @@ -794,6 +794,7 @@ use 'plain-file' instead~%")
>    ;; Default set of setuid-root programs.
>    (let ((shadow (@ (gnu packages admin) shadow)))
>      (list (file-append shadow "/bin/passwd")
> +          (file-append shadow "/bin/chsh")
>            (file-append shadow "/bin/su")
>            (file-append shadow "/bin/newuidmap")
>            (file-append shadow "/bin/newgidmap")
> diff --git a/gnu/system/pam.scm b/gnu/system/pam.scm
> index 13f76a50ed..27239c5621 100644
> --- a/gnu/system/pam.scm
> +++ b/gnu/system/pam.scm
> @@ -1,5 +1,5 @@
>  ;;; GNU Guix --- Functional package management for GNU
> -;;; Copyright © 2013, 2014, 2015, 2016, 2017 Ludovic Courtès <ludo@gnu.org>
> +;;; Copyright © 2013, 2014, 2015, 2016, 2017, 2019 Ludovic Courtès <ludo@gnu.org>
>  ;;;
>  ;;; This file is part of GNU Guix.
>  ;;;
> @@ -265,7 +265,7 @@ authenticate to run COMMAND."
>            ;; These programs are setuid-root.
>            (map (cut unix-pam-service <>
>                      #:allow-empty-passwords? allow-empty-passwords?)
> -               '("passwd" "sudo"))
> +               '("passwd" "chsh" "sudo"))
>            ;; This is setuid-root, as well.  Allow root to run "su" without
>            ;; authenticating.
>            (list (unix-pam-service "su"
> -- 
> 2.21.0
>
> From 6ab1ecd628f13829e31e4bcbe7bf0ff53951eedd Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Ludovic=20Court=C3=A8s?= <ludo@gnu.org>
> Date: Thu, 25 Apr 2019 12:23:11 +0200
> Subject: [PATCH 2/2] doc: Document 'chsh'.
>
> * doc/guix.texi (User Accounts): Document 'chsh'.
> ---
>  doc/guix.texi | 9 +++++++++
>  1 file changed, 9 insertions(+)
>
> diff --git a/doc/guix.texi b/doc/guix.texi
> index 879cb562e9..b5048f7269 100644
> --- a/doc/guix.texi
> +++ b/doc/guix.texi
> @@ -11000,6 +11000,15 @@ if it does not exist yet.
>  This is a G-expression denoting the file name of a program to be used as
>  the shell (@pxref{G-Expressions}).
>  
> +Users may change their shell at any time by running the @command{chsh}
> +command---run @command{man chsh} for more info.  The list of allowed shells
> +can be found in the @file{/etc/shells} file, which is itself the combination
> +of the @code{shell} fields of all the user accounts.
> +
> +Because the account's shell is user-modifiable system state---just like
> +passwords---it is preserved across reboots and reconfiguration, even if the
> +administrator changes the value of the @code{shell} field.
> +
>  @item @code{system?} (default: @code{#f})
>  This Boolean value indicates whether the account is a ``system''
>  account.  System accounts are sometimes treated specially; for instance,

Re: User shell: state or config?

[Tobias Geerinckx-Rice]

[-- Attachment #1: Type: text/plain, Size: 920 bytes --]

Ludo', all,

mikadoZero wrote:
> Ludovic Courtès writes:

[…]

>> However, thinking more about it, I’m not sure if considering 
>> shells as
>> state is such a good idea, for several reasons:
>>
>>   1. It’s surprising that ‘guix system reconfigure’ doesn’t 
>>   actually
>>      change the shell, as Tanguy reported.
>
> As a new user of Guix System I was recently surprised by this as 
> well.
> I was expecting the shell to be managed by configuration.

As an old user, I agree ;-)

It's so surprising because we don't set ‘user-overridable 
defaults’ for state anywhere else.  You can't reason about your 
system the way you used to.  The config is a lie.

> All in all, I’m in favor of switching back to the previous 
> behavior:
> considering user shells as system config.  That’s a one-line 
> change in
> (gnu build accounts).

+1!

Kind regards,

T G-R

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

Re: User shell: state or config?

[Chris Marusich]

[-- Attachment #1: Type: text/plain, Size: 732 bytes --]

Tobias Geerinckx-Rice <me@tobias.gr> writes:

>> All in all, I’m in favor of switching back to the previous behavior:
>> considering user shells as system config.  That’s a one-line change
>> in
>> (gnu build accounts).
>
> +1!

+1 from me as well.  Allowing the shell to be declaratively defined in
the system config, but also allowing a user to override it permanently
at runtime via chsh, seems like a nice middle ground between treating it
as "config" vs. "state".

I think in Guix System it is generally better to treat as much as
possible as "config".  After all, Guix System is basically an exercise
in extending the functional software deployment model to whole-system
management, right?

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: User shell: state or config?

[Tanguy Le Carrour]

Hello Guix!


Le 04/25, Ludovic Courtès a écrit :
> We recently discussed handling of the ‘shell’ field of ‘user-account’:
> 
>   https://lists.gnu.org/archive/html/help-guix/2019-04/msg00171.html

Thanks for taking the time to think about it! :-)


> Considering user shells as state seemed like a good idea
> […]
> All in all, I’m in favor of switching back to the previous behavior

I don't yet understand the consequences of this choice, so I don't have an
opinion on this. For instance, I don't yet understand why, on my system, two
shells installed "system wide" with `guix system reconfigure`
(namely bash and fish) don't have the same "type" of path [1]?
I was expecting fish to be in the `/run/current-system/profile/bin/`
folder. And what about the second bash?!

[1]: from `/etc/shells`
     /run/current-system/profile/bin/bash
     /gnu/store/qn1ax1fkj16x280m1rv7mcimfmn9l2pf-bash-4.4.23/bin/bash
     /gnu/store/9r5z8k0p0ilmg8qfyc82x11ybacawfqa-fish-3.0.2/bin/fish

Best regards


-- 
Tanguy

Re: User shell: state or config?

[Meiyo Peng]

Hi Ludovic,

Ludovic Courtès writes:

> All in all, I’m in favor of switching back to the previous behavior:
> considering user shells as system config.  That’s a one-line change in
> (gnu build accounts).
>
> Thoughts?

I support this change.  You have listed very good reasons.

Last month, I installed Guix system on my computer with a minimal Guix
config and then reconfigure the system with a more complete Guix config.
I was surprised that my login shell is still bash while the user's shell
slot in Guix config has been changed to fish.


--
Meiyo Peng
https://www.pengmeiyu.com/

Re: User shell: state or config?

[Ludovic Courtès]

Hello,

Chris Marusich <cmmarusich@gmail.com> skribis:

> Tobias Geerinckx-Rice <me@tobias.gr> writes:
>
>>> All in all, I’m in favor of switching back to the previous behavior:
>>> considering user shells as system config.  That’s a one-line change
>>> in
>>> (gnu build accounts).
>>
>> +1!
>
> +1 from me as well.

Done in 504a0fc636ec591e65b4a229a37e522e425d8a0c.

> Allowing the shell to be declaratively defined in the system config,
> but also allowing a user to override it permanently at runtime via
> chsh, seems like a nice middle ground between treating it as "config"
> vs. "state".

In this particular case there’s no middle ground though: either you
consider state and then you have the problems I listed, or you consider
it config.  I did think there was a middle ground, until I realized the
implications.

Thanks everyone for your feedback!

Ludo’.

Re: User shell: state or config?

[Ludovic Courtès]

Hi,

Tanguy Le Carrour <tanguy@bioneland.org> skribis:

> I don't yet understand the consequences of this choice, so I don't have an
> opinion on this. For instance, I don't yet understand why, on my system, two
> shells installed "system wide" with `guix system reconfigure`
> (namely bash and fish) don't have the same "type" of path [1]?
> I was expecting fish to be in the `/run/current-system/profile/bin/`
> folder. And what about the second bash?!
>
> [1]: from `/etc/shells`
>      /run/current-system/profile/bin/bash
>      /gnu/store/qn1ax1fkj16x280m1rv7mcimfmn9l2pf-bash-4.4.23/bin/bash
>      /gnu/store/9r5z8k0p0ilmg8qfyc82x11ybacawfqa-fish-3.0.2/bin/fish

/etc/shells is one of these good ol’ Unix hacks, like /etc/fstab, that
don’t make much sense on Guix, but that we provide to please a number of
programs that rely on it (in this case: xterm and polkit, notably, and
chsh.)

You can find in (gnu system shadow) the code that creates this file.
The first three lines are added systematically, while the others are
derived from user accounts.

HTH,
Ludo’.