Non-default umask when using guix system leads to wrong file permissions

  • Open
  • quality assurance status badge
Details
2 participants
  • Josselin Poiret
  • Ludovic Courtès
Owner
unassigned
Submitted by
Josselin Poiret
Severity
important
J
J
Josselin Poiret wrote on 27 Oct 2021 17:24
(address . bug-guix@gnu.org)
87wnlya3tn.fsf@jpoiret.xyz
Hi,

As reported on IRC by wonko
‘guix system’ under a different umask, some files are created with the
wrong permissions. This can happen because ‘sudo’ does by default keeps
the umask it is running on (by ORing it with the default one, often
022).

I'm not sure what would be the best way to go about this, I suggest
checking if umask == #o022, and if not, print a warning and set it to
#o022, and only in ‘guix system’.

What do you think?

Best,
Josselin Poiret
L
L
Ludovic Courtès wrote on 29 Oct 2021 00:45
control message for bug #51442
(address . control@debbugs.gnu.org)
875ytg4vlz.fsf@gnu.org
severity 51442 important
quit
L
L
Ludovic Courtès wrote on 29 Oct 2021 21:10
Re: bug#51442: Non-default umask when using guix system leads to wrong file permissions
(name . Josselin Poiret)(address . dev@jpoiret.xyz)(address . 51442@debbugs.gnu.org)
87k0hvy7cz.fsf@gnu.org
Hi,

Josselin Poiret <dev@jpoiret.xyz> skribis:

Toggle quote (3 lines)
> As reported on IRC by wonko
> (https://logs.guix.gnu.org/guix/2021-10-27.log#115445),

wonko mentions files in /etc (those are created by the activation
snippets).

Toggle quote (9 lines)
> when running ‘guix system’ under a different umask, some files are
> created with the wrong permissions. This can happen because ‘sudo’
> does by default keeps the umask it is running on (by ORing it with the
> default one, often 022).
>
> I'm not sure what would be the best way to go about this, I suggest
> checking if umask == #o022, and if not, print a warning and set it to
> #o022, and only in ‘guix system’.

Perhaps the best fix would be to set the umask explicitly before
activation snippets run, like so (untested):
Toggle diff (15 lines)
diff --git a/gnu/services.scm b/gnu/services.scm
index 1655218f2d..b79436d3f3 100644
--- a/gnu/services.scm
+++ b/gnu/services.scm
@@ -617,6 +617,10 @@ (define actions
(use-modules (gnu build activation)
(guix build utils))
+ ;; Set the correct umask so files are created with the
+ ;; expected permissions.
+ (umask #o022)
+
;; Make sure the user accounting database exists. If it
;; does not exist, 'setutxent' does not create it and
;; thus there is no accounting at all.
WDYT?

Thanks,
Ludo’.
J
J
Josselin Poiret wrote on 30 Oct 2021 22:48
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 51442@debbugs.gnu.org)
87zgqqz1bh.fsf@jpoiret.xyz
Hi,

Ludovic Courtès <ludo@gnu.org> writes:
Toggle quote (5 lines)
> Perhaps the best fix would be to set the umask explicitly before
> activation snippets run, like so (untested):
> [snip]
> WDYT?

I forgot about those too! I guess they're run in two different contexts:
once when `guix reconfigure` happens, and another one in the boot
script. This would work here, but not be nearly enough: in init, you
also have the populate-root-file-system procedure which will create many
directories without set permissions, and if they are created with a-r,
it will also cause havok (I think the first issue wonko reported was
about the directories not being readable).

I still think that the whole init/reconfigure commands should have their
umask set to #o022 as a sane default, even for future changes to them:
whatever they're touching is supposed to be "the system" itself and not
user files, so inherited user-set umasks shouldn't matter. It just feels
like we're trying to fight back against 'sudo' preserving things when it
shouldn't but alas.

Best,
Josselin Poiret
?
Your comment

Commenting via the web interface is currently disabled.

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

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