Bug when moving between system instances

  • Done
  • quality assurance status badge
Details
2 participants
  • goglosh
  • Ludovic Courtès
Owner
unassigned
Submitted by
goglosh
Severity
normal
G
G
goglosh wrote on 26 Sep 2015 05:21
(address . bug-guix@gnu.org)
b4dbc90ccd9f0a0e5d6419f9d309f9b1@openmailbox.org
Hello.
I got this unexpected behaviour. I used `guix system reconfigure ...` to
make a new system instance, used it for a while, and later booted back
into the old system. I used diferent names for the user in the first and
second system, let's call them sys1user and sys2user. I booted into the
old system and tried to login as sys1user (the user created with that
system) with it's password and this was no longer possible. root
remained untouched, so I used root to change the password and login as
usual. Done that I discovered I didn't have access to the files of
user1.
I then rebooted back into the new system, only to find the exact same
problem. in /home/sys2user all files belonged to some user called 30011.
I could of course change permissions for most of them using sudo, all
but the all-important ~/.guix-profile. Since it's a symlink to a
read-only filesystem, this was impossible.
Thanks for listening, and, sorry about the non-technical bug report.
L
L
Ludovic Courtès wrote on 26 Sep 2015 22:21
(address . goglosh@openmailbox.org)(address . 21566@debbugs.gnu.org)
87612xylrj.fsf@gnu.org
goglosh@openmailbox.org skribis:

Toggle quote (8 lines)
> I got this unexpected behaviour. I used `guix system reconfigure ...`
> to make a new system instance, used it for a while, and later booted
> back into the old system. I used diferent names for the user in the
> first and second system, let's call them sys1user and sys2user. I
> booted into the old system and tried to login as sys1user (the user
> created with that system) with it's password and this was no longer
> possible.

Yes, good point. I see how this may look confusing.

When you boot a specific generation of the system, it gets to see only
the set of users that were declared for that generation. So one sees
‘sys1user’ and ‘root’, and the other has ‘sys2user’ and ‘root’.

So when you booted the new generation, the ‘sys1user’ account was
deleted and the ‘sys2user’ account was created. When you booted again
into the old generation, ‘sys1user’ was added back and ‘sys2user’ was
deleted. This is on purpose, see http://bugs.gnu.org/19795.

Now, the problem is that passwords are state that is outside of GuixSD’s
control. Passwords are stored in /etc/shadow, and removing a user
account removes its entry in /etc/shadow. This is why you would get
uninitialized passwords when booting back in the old generation.

I think this is an acceptable “limitation” of the approach though.

Toggle quote (4 lines)
> I then rebooted back into the new system, only to find the exact same
> problem. in /home/sys2user all files belonged to some user called
> 30011.

Same issue: Unless the ‘user-account’ declaration asked for a specific
user ID via the ‘uid’ field (see
the UID is assigned when the account is first created.

What happens here is that maybe ‘sys2user’ got the UID 30011 at some
point, and then got a different one.

Again, I don’t thin there’s much that GuixSD can do here, because it
doesn’t control what files are created under which UID in /home, etc.

Does that make sense?

Thanks,
Ludo’.
L
L
Ludovic Courtès wrote on 2 Nov 2015 23:56
control message for bug #21566
(address . control@debbugs.gnu.org)
871tc8ui16.fsf@gnu.org
tags 21566 notabug
L
L
Ludovic Courtès wrote on 2 Nov 2015 23:57
(address . control@debbugs.gnu.org)
87ziywt3ge.fsf@gnu.org
close 21566 0.8.3
?
Your comment

This issue is archived.

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

To respond to this issue using the mumi CLI, first switch to it
mumi current 21566
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