bug-guix
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#36785: Impossible to pull on foreign distro


From: Maxim Cournoyer
Subject: bug#36785: Impossible to pull on foreign distro
Date: Fri, 20 Sep 2019 17:47:11 +0900
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)

Hello,

Gábor Boskovits <address@hidden> writes:

> Hello Ludo,
>
> Ludovic Courtès <address@hidden> ezt írta (időpont: 2019. szept. 18., Sze,
> 0:04):
>
>> Hi,
>>
>> Ludovic Courtès <address@hidden> skribis:
>>
>> > Indeed.  I added ‘pk’ calls to print ‘%profile-directory’ and
>> > (canonicalize-profile %user-profile-directory), and here’s what I see
>> > with ‘sudo’:
>> >
>> > $ sudo -E ./pre-inst-env guix pull
>> >
>> > ;;; (pd "/var/guix/profiles/per-user/root")
>> >
>> > ;;; (upd "/home/ludo/.config/guix/current")
>>
>> I used ‘-E’ above, which is why HOME was ~ludo instead of ~root.
>> Without ‘-E’, HOME is ~root as expected, and so “sudo guix pull” does
>> the right thing (this is on Guix System):
>>
>> --8<---------------cut here---------------start------------->8---
>> $ sudo guix repl
>> GNU Guile 2.2.4
>> Copyright (C) 1995-2017 Free Software Foundation, Inc.
>>
>> Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
>> This program is free software, and you are welcome to redistribute it
>> under certain conditions; type `,show c' for details.
>>
>> Enter `,help' for help.
>> scheme@(guix-user)> (getenv "HOME")
>> $1 = "/root"
>> scheme@(guix-user)> ,m(guix scripts pull)
>> scheme@(guix scripts pull)> %profile-directory
>> $2 = "/var/guix/profiles/per-user/root"
>> scheme@(guix scripts pull)> %user-profile-directory
>> $3 = "/root/.config/guix/current"
>> scheme@(guix scripts pull)> (cache-directory)
>> $4 = "/root/.cache/guix"
>> scheme@(guix scripts pull)> (config-directory)
>> $5 = "/root/.config/guix"
>> --8<---------------cut here---------------end--------------->8---
>>
>> So ‘sudo guix pull’ really updates root’s profile and writes to
>> ~root/.cache, everything is fine.
>>
>> Done?
>>
>> I investigated a bit, tried Debian, then Ubuntu, and found that ‘sudo’
>> on Ubuntu behaves differently: it preserves ‘HOME’ by default:
>>
>>   $ sudo env | grep HOME
>>   HOME=/home/ubuntu
>>
>> This is written here:
>>
>>
>> https://help.ubuntu.com/community/RootSudo#Special_notes_on_sudo_and_shells
>>
>> (That’s with sudo 1.8.21p2, FWIW.)
>>
>> Ubuntu’s /etc/sudoers doesn’t have anything special.  Actually, Debian
>> has (almost) the same /etc/sudoers and yet it does not preserve HOME.
>>
>> (Time passes…)
>>
>> Digging further, I fetched the source from
>> <https://packages.ubuntu.com/bionic/sudo>, and boom! I found the
>> culprit: it’s called ‘debian/patches/keep_home_by_default.patch’.
>>
>> --8<---------------cut here---------------start------------->8---
>> Description: Set HOME in initial_keepenv_table
>>  Set HOME in initial_keepenv_table; without this, $HOME will never be
>>  preserved unless added to keep_env.  There's appropriate logic to handle
>>  resetting the home for -H and -i options, so this is the only part that's
>>  missing.
>> Author: Steve Langasek <address@hidden>
>> --- a/plugins/sudoers/env.c
>> +++ b/plugins/sudoers/env.c
>> @@ -189,6 +189,7 @@
>>      "COLORS",
>>      "DISPLAY",
>>      "DPKG_COLORS",
>> +    "HOME",
>>      "HOSTNAME",
>>      "KRB5CCNAME",
>>      "LS_COLORS",
>> --8<---------------cut here---------------end--------------->8---
>>
>> (This patch is playing with fire IMO.  If you’re an Ubuntu user,
>> consider reporting a bug!)
>>
>> But anyway, what can we do?
>>
>> We could ignore the issue, it’s-Ubuntu’s-fault, done.
>>
>> We could also add some logic to detect whether (1) we’re running under
>> sudo, and in that case, and whether (2) $HOME matches $USER’s home
>> directory as it appears in /etc/passwd.  If both conditions are
>> satisfied, we could ignore $HOME and use the home directory from
>> /etc/passwd instead.
>>
>> But… that’s complicated, and it’d break uses of ‘sudo -H’.
>>
>> We could apply the patch I posted earlier, which simply disables profile
>> migration when SUDO_USER is set.  That won’t address the fact that root
>> writes to the user’s ~/.cache, but there’s not much we can do here.
>>
>> Thoughts?
>>
>
> We could simply document a proper sudo invocation for updating root's guix,
> that
> always works. Wdyt?
>
> We could provide it simply as a hint if it fails.

Indeed, the default recommended invocation to update the root's guix
could be changed to be 'sudo -i guix pull', which should work on all
systems including Ubuntu.

Maxim





reply via email to

[Prev in Thread] Current Thread [Next in Thread]