Fwd: Comments in /etc/passwd don't get updated

In my Guix system's /etc/passwd file, my user named "abc" has a

comment attached to it. The relevant line is:

abc:x:1000:998:Old

Comment:/home/jkf:/gnu/store/71yp1p06jy2j96bfdz43f4p6ncdym5a1-zsh-5.8/bin/zsh

Today the users section of my current config.scm looks like this:

(users (cons* (user-account

(name "abc")

(group "users")

(comment "New Comment")

(supplementary-groups '("wheel"

"netdev"

"audio"

"video"

"disk"

"cdrom"

"docker"

"libvirt"

"kvm"))

(shell #~(string-append #$zsh "/bin/zsh")))

%base-user-accounts))

After I apply this configuration with `guix system reconfigure', I

expect /etc/passwd to have been updated with "New Comment" in place of

"Old Comment". However, "Old Comment" remains.

Similarly, if I omit the `comment' field entirely, I expect my user

comment to be removed from /etc/passwd, since the default value of the

`comment' field is documented to be an empty string (manual 10.6).

Again, the old comment remains.

I am reporting this on a recent Guix version cev9c6c5, but have

noticed this issue for a year at least.

Hi,

Am Donnerstag, dem 16.12.2021 um 07:00 +0000 schrieb Jacob First:

What if you were to temporarily change your login shell to let's say

bash? IIRC, Guix is quite lazy when it comes to updating these values,

but a change in the shell ought to get them revised. I think the

reason behind it is that it doesn't want to lock you out by messing

with the password field, but that's a little unrelated here.

Cheers

Changing the shell indeed causes the comment to be updated.

If lazy update is the correct behavior, then the docs about user

accounts are a bit misleading:

"When booting or upon completion of guix system reconfigure, the

system ensures that only the user accounts and groups specified in the

operating-system declaration exist, and with the specified properties.

Thus, account or group creations or modifications made by directly

invoking commands such as useradd are lost upon reconfiguration or

reboot. This ensures that the system remains exactly as declared."

As a user it would be helpful to know from the docs that some of the

fields actually persist across reboots/reconfigurations.

Thanks for the workaround in any case!

On Fri, Dec 17, 2021 at 4:02 AM Liliana Marie Prikler

<liliana.prikler@gmail.com> wrote:

Hi,

Jacob First <jacob.first@member.fsf.org> skribis:

This is on purpose, per these lines in ‘allocate-passwd’ in (gnu build

accounts):

(real-name (if previous

(password-entry-real-name previous)

real-name))

This wasn’t a firm decision, but I think the rationale here could be

that we’d rather allow users to change their name with ‘chfn’ to

something other than what the sysadmin chose, than enforce the

sysadmin’s choice. (Except that ‘chfn’ is currently not setuid by

default on Guix System, so the scenario above is unlikely.)

Thoughts?

Thanks,

Ludo’.

Thanks for the explanation. This rationale sounds reasonable to me. If

someone with proper permission has modified a user account's comment,

it could be important to preserve that customization.

As I pointed out in an earlier message, I believe this behavior

contradicts the documentation of the `user-account' data type pretty

strongly. So it appears there is at least a "doc bug" here.

FWIW, I actually reported the present behavior as a bug not because of

the doc issue, but based on an assumption that "purely declarative"

implied the result of applying a given configuration should not depend

on any preexisting system state like a user comment. Sorry for not

making that clear: it seemed obvious, but I think it's actually a

misconception (even if user accounts are one of the few areas, AFAICT,

where the property doesn't hold true).

On Wed, Dec 22, 2021 at 10:36 PM Ludovic Courtès <ludo@gnu.org> wrote:

Hi Jacob,

Jacob First <jacob.first@member.fsf.org> skribis:

I clarified this and ensures ‘chfn’ is actually usable in commit

c76775263e56a10cc1b84d03a5827f42436afe40.

Thanks!

Ludo’.

Oops, I hadn’t pushed; the right commit ID is

671e6a81804f264ddcdd6fe7579644404da079b8.

Ludo’.