bug#64775: /run should be cleaned on boot

bug#64775: /run should be cleaned on boot

[Vagrant Cascadian]

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

So, if there are files sitting around in /run, they do not get cleaned
up unless it is something guix is already aware of
(e.g. /run/setuid-programs).

I noticed this when experimenting with:

  https://issues.guix.gnu.org/61462
  Add support for file capabilities(7)

Even after a reboot, the leftovers from that experimental patchset were
still present in /run...

While I know that Guix does not really follow the FHS in most respects,
maybe the intention of /run defined there should still be respected?

  https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s15.html

  3.15. /run : Run-time variable data
  3.15.1. Purpose

  This directory contains system information data describing the system
  since it was booted. Files under this directory must be cleared
  (removed or truncated as appropriate) at the beginning of the boot
  process.
  ...

Many distros implement this by having /run on a tmpfs, but making sure
to clean up /run at boot seems like a reasonable thing to do at the very
least.

I am not sure if it makes sense to do housecleaning of /run from guix
system reconfigure ... as there may be legitimate uses for other
processes to write there.


live well,
  vagrant

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

bug#64775: /run should be cleaned on boot

[Csepp]

Vagrant Cascadian <vagrant@debian.org> writes:

> [[PGP Signed Part:Undecided]]
> So, if there are files sitting around in /run, they do not get cleaned
> up unless it is something guix is already aware of
> (e.g. /run/setuid-programs).
>
> I noticed this when experimenting with:
>
>   https://issues.guix.gnu.org/61462
>   Add support for file capabilities(7)
>
> Even after a reboot, the leftovers from that experimental patchset were
> still present in /run...
>
> While I know that Guix does not really follow the FHS in most respects,
> maybe the intention of /run defined there should still be respected?
>
>   https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s15.html
>
>   3.15. /run : Run-time variable data
>   3.15.1. Purpose
>
>   This directory contains system information data describing the system
>   since it was booted. Files under this directory must be cleared
>   (removed or truncated as appropriate) at the beginning of the boot
>   process.
>   ...
>
> Many distros implement this by having /run on a tmpfs, but making sure
> to clean up /run at boot seems like a reasonable thing to do at the very
> least.
>
> I am not sure if it makes sense to do housecleaning of /run from guix
> system reconfigure ... as there may be legitimate uses for other
> processes to write there.
>
>
> live well,
>   vagrant
>
> [[End of PGP Signed Part]]

I vote for TMPFS, since that would also reduce flash wear.
Honestly I don't get why it's not already using TMPFS.

bug#64775: /run should be cleaned on boot

[Vagrant Cascadian]

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

On 2023-07-21, Csepp wrote:
> Vagrant Cascadian <vagrant@debian.org> writes:
>> While I know that Guix does not really follow the FHS in most respects,
>> maybe the intention of /run defined there should still be respected?
>>
>>   https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s15.html
>>
>>   3.15. /run : Run-time variable data
>>   3.15.1. Purpose
>>
>>   This directory contains system information data describing the system
>>   since it was booted. Files under this directory must be cleared
>>   (removed or truncated as appropriate) at the beginning of the boot
>>   process.
>>   ...
>>
>> Many distros implement this by having /run on a tmpfs, but making sure
>> to clean up /run at boot seems like a reasonable thing to do at the very
>> least.
>>
>> I am not sure if it makes sense to do housecleaning of /run from guix
>> system reconfigure ... as there may be legitimate uses for other
>> processes to write there.
...
> I vote for TMPFS, since that would also reduce flash wear.
> Honestly I don't get why it's not already using TMPFS.

One argument could be how much ram it takes:

  $ du -sc /run/*
  12      /run/blkid
  0       /run/booted-system
  0       /run/current-system
  1312    /run/setuid-programs
  524     /run/udev
  1848    total

That is with no explicit setuid programs configured, on a machine with a
fairly minimal configuration.

Not a *huge* amount of ram, but not nothing, either...

live well,
  vagrant

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

bug#64775: /run should be cleaned on boot

[Saku Laesvuori via Bug reports for GNU Guix]

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

> > I vote for TMPFS, since that would also reduce flash wear.
> > Honestly I don't get why it's not already using TMPFS.
>
> One argument could be how much ram it takes:
> 
>   $ du -sc /run/*
>   12      /run/blkid
>   0       /run/booted-system
>   0       /run/current-system
>   1312    /run/setuid-programs
>   524     /run/udev
>   1848    total
> 
> That is with no explicit setuid programs configured, on a machine with a
> fairly minimal configuration.
> 
> Not a *huge* amount of ram, but not nothing, either...

I'd say it's effectively nothing for almost all devices capable of
running Guix. On my laptop the size of /run is 4804 (4.7M). In a quick
test one terminal window with only zsh running in it took almost 10
times as much ram.

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

bug#64775: /run should be cleaned on boot

[Hilton Chain via Bug reports for GNU Guix]

Hi all,

On Sat, 22 Jul 2023 04:24:17 +0800,
Saku Laesvuori via Bug reports for GNU Guix wrote:
>
> [1  <text/plain; us-ascii (quoted-printable)>]
> > > I vote for TMPFS, since that would also reduce flash wear.
> > > Honestly I don't get why it's not already using TMPFS.
> >
> > One argument could be how much ram it takes:
> >
> >   $ du -sc /run/*
> >   12      /run/blkid
> >   0       /run/booted-system
> >   0       /run/current-system
> >   1312    /run/setuid-programs
> >   524     /run/udev
> >   1848    total
> >
> > That is with no explicit setuid programs configured, on a machine with a
> > fairly minimal configuration.
> >
> > Not a *huge* amount of ram, but not nothing, either...
>
> I'd say it's effectively nothing for almost all devices capable of
> running Guix. On my laptop the size of /run is 4804 (4.7M). In a quick
> test one terminal window with only zsh running in it took almost 10
> times as much ram.
> [2 signature.asc <application/pgp-signature (7bit)>]
> No public key for 257D284A2A1D3A32 created at 2023-07-22T04:24:17+0800 using RSA

I'm currently using tmpfs for /tmp, /run and /var/run on my Guix
Systems.

If you are interested, this is my base file systems:
--8<---------------cut here---------------start------------->8---
(cons* (file-system
         (device "none")
         (mount-point "/tmp")
         (type "tmpfs")
         (check? #f))

       (file-system
         (device "none")
         (mount-point "/run")
         (type "tmpfs")
         (needed-for-boot? #t)
         (check? #f))

       (file-system
         (device "none")
         (mount-point "/var/run")
         (type "tmpfs")
         (needed-for-boot? #t)
         (check? #f))

       (delete %debug-file-system
               %base-file-systems))
--8<---------------cut here---------------end--------------->8---

Thanks

bug#64775: /run should be cleaned on boot

[Vagrant Cascadian]

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

On 2023-08-06, Hilton Chain wrote:
> On Sat, 22 Jul 2023 04:24:17 +0800,
> Saku Laesvuori via Bug reports for GNU Guix wrote:
>>
>> [1  <text/plain; us-ascii (quoted-printable)>]
>> > > I vote for TMPFS, since that would also reduce flash wear.
>> > > Honestly I don't get why it's not already using TMPFS.
>> >
>> > One argument could be how much ram it takes:
>> >
>> >   $ du -sc /run/*
>> >   12      /run/blkid
>> >   0       /run/booted-system
>> >   0       /run/current-system
>> >   1312    /run/setuid-programs
>> >   524     /run/udev
>> >   1848    total
>> >
>> > That is with no explicit setuid programs configured, on a machine with a
>> > fairly minimal configuration.
>> >
>> > Not a *huge* amount of ram, but not nothing, either...
>>
>> I'd say it's effectively nothing for almost all devices capable of
>> running Guix. On my laptop the size of /run is 4804 (4.7M). In a quick
>> test one terminal window with only zsh running in it took almost 10
>> times as much ram.
>> [2 signature.asc <application/pgp-signature (7bit)>]
>> No public key for 257D284A2A1D3A32 created at 2023-07-22T04:24:17+0800 using RSA
>
> I'm currently using tmpfs for /tmp, /run and /var/run on my Guix
> Systems.
>
> If you are interested, this is my base file systems:
> --8<---------------cut here---------------start------------->8---
> (cons* (file-system
>          (device "none")
>          (mount-point "/tmp")
>          (type "tmpfs")
>          (check? #f))
>
>        (file-system
>          (device "none")
>          (mount-point "/run")
>          (type "tmpfs")
>          (needed-for-boot? #t)
>          (check? #f))
>
>        (file-system
>          (device "none")
>          (mount-point "/var/run")
>          (type "tmpfs")
>          (needed-for-boot? #t)
>          (check? #f))

You probably want to restrict permissions on /run and /var/run, as the
defaults for tmpfs are world-writeable, allowing any user or process to
create files or directories in potentially harmful ways...

For /tmp, these defaults are appropriate, however tricky a
world-writeable directory is...

Although I rarely have enough spare ram on a system to have /tmp be
tmpfs for Guix System because builds happen there by default, and
occasionally I need a lot more space than available ram in some cases.


live well,
  vagrant

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

bug#64775: /run should be cleaned on boot

[Hilton Chain via Bug reports for GNU Guix]

On Mon, 07 Aug 2023 04:06:37 +0800,
Vagrant Cascadian wrote:
>
> [1  <text/plain (7bit)>]
> On 2023-08-06, Hilton Chain wrote:
> > On Sat, 22 Jul 2023 04:24:17 +0800,
> > Saku Laesvuori via Bug reports for GNU Guix wrote:
> >>
> >> [1  <text/plain; us-ascii (quoted-printable)>]
> >> > > I vote for TMPFS, since that would also reduce flash wear.
> >> > > Honestly I don't get why it's not already using TMPFS.
> >> >
> >> > One argument could be how much ram it takes:
> >> >
> >> >   $ du -sc /run/*
> >> >   12      /run/blkid
> >> >   0       /run/booted-system
> >> >   0       /run/current-system
> >> >   1312    /run/setuid-programs
> >> >   524     /run/udev
> >> >   1848    total
> >> >
> >> > That is with no explicit setuid programs configured, on a machine with a
> >> > fairly minimal configuration.
> >> >
> >> > Not a *huge* amount of ram, but not nothing, either...
> >>
> >> I'd say it's effectively nothing for almost all devices capable of
> >> running Guix. On my laptop the size of /run is 4804 (4.7M). In a quick
> >> test one terminal window with only zsh running in it took almost 10
> >> times as much ram.
> >> [2 signature.asc <application/pgp-signature (7bit)>]
> >> No public key for 257D284A2A1D3A32 created at 2023-07-22T04:24:17+0800 using RSA
> >
> > I'm currently using tmpfs for /tmp, /run and /var/run on my Guix
> > Systems.
> >
> > If you are interested, this is my base file systems:
> > --8<---------------cut here---------------start------------->8---
> > (cons* (file-system
> >          (device "none")
> >          (mount-point "/tmp")
> >          (type "tmpfs")
> >          (check? #f))
> >
> >        (file-system
> >          (device "none")
> >          (mount-point "/run")
> >          (type "tmpfs")
> >          (needed-for-boot? #t)
> >          (check? #f))
> >
> >        (file-system
> >          (device "none")
> >          (mount-point "/var/run")
> >          (type "tmpfs")
> >          (needed-for-boot? #t)
> >          (check? #f))
>
> You probably want to restrict permissions on /run and /var/run, as the
> defaults for tmpfs are world-writeable, allowing any user or process to
> create files or directories in potentially harmful ways...
>
> For /tmp, these defaults are appropriate, however tricky a
> world-writeable directory is...

I have set the mode and size limit on them.

Thank you so much!  Otherwise I won't notice that...

> Although I rarely have enough spare ram on a system to have /tmp be
> tmpfs for Guix System because builds happen there by default, and
> occasionally I need a lot more space than available ram in some cases.

I have enough RAM for builds I currently do on my laptop and it's the
builder for other systems, so tmpfs is fine for me.

Thanks

bug#64775: /run should be cleaned on boot

[Maxim Cournoyer]

Hi,

Hilton Chain via Bug reports for GNU Guix <bug-guix@gnu.org> writes:

> Hi all,
>
> On Sat, 22 Jul 2023 04:24:17 +0800,
> Saku Laesvuori via Bug reports for GNU Guix wrote:
>>
>> [1  <text/plain; us-ascii (quoted-printable)>]
>> > > I vote for TMPFS, since that would also reduce flash wear.
>> > > Honestly I don't get why it's not already using TMPFS.
>> >
>> > One argument could be how much ram it takes:
>> >
>> >   $ du -sc /run/*
>> >   12      /run/blkid
>> >   0       /run/booted-system
>> >   0       /run/current-system
>> >   1312    /run/setuid-programs
>> >   524     /run/udev
>> >   1848    total
>> >
>> > That is with no explicit setuid programs configured, on a machine with a
>> > fairly minimal configuration.
>> >
>> > Not a *huge* amount of ram, but not nothing, either...
>>
>> I'd say it's effectively nothing for almost all devices capable of
>> running Guix. On my laptop the size of /run is 4804 (4.7M). In a quick
>> test one terminal window with only zsh running in it took almost 10
>> times as much ram.
>> [2 signature.asc <application/pgp-signature (7bit)>]
>> No public key for 257D284A2A1D3A32 created at 2023-07-22T04:24:17+0800 using RSA
>
> I'm currently using tmpfs for /tmp, /run and /var/run on my Guix
> Systems.

Without reviewing how our code base uses /run, it seems reasonable that
this should be on a tmpfs.  Can anyone think of a reason not to do so?
Otherwise, I suggest we make it so.

-- 
Thanks,
Maxim

[bug#61462] Add support for file capabilities(7)

[Tobias Geerinckx-Rice via Guix-patches via]

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

Hi Guix,

I need to offload some of my eternally rebased local patches. 
Here's one that makes it easy to assign capabilities(7) — 
currently through setcap(8) — to programmes like we can 
set{u,g}id.

There are many packages that benefit from this.  Mine are:

  (privileged-programs
    (cons* (privileged-program
            (file-append mtr "/sbin/mtr")
            (capabilities "cap_net_raw+ep"))
           (privileged-program
            (file-append nethogs "/sbin/nethogs")
            (capabilities "cap_net_admin,cap_new_raw+ep"))
           (privileged-program
            (file-append light "/bin/light")
            (setuid? #t))
           %default-privileged-programs))

The set's over a year old and needs a bit of love.  Some details 
might have bitrot, I probably forgot a to-do or two in that year, 
and there's something unguixy about calling setcap(8) instead of 
writing a completely new Guile binding/module :-)

I'm quite opinionated about the setuid-programs unification: there 
should not be multiple confusing and masking layers of privilege, 
and it should be possible to setgid a capable executable.

Kind regards,

T G-R

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

[bug#61462] [PATCH v2 01/10] system: Disallow file-like setuid-programs.

[Tobias Geerinckx-Rice via Guix-patches via]

It has been a warning for well over a year now.  Now, with
privileged-programs coming, don't let's support nested deprecation
hacks.

* gnu/system.scm (<operating-system>):
Don't ‘sanitize’ the setuid-programs field.
(ensure-setuid-program-list): Delete syntax.
(%ensure-setuid-program-list): Delete variable.
---

This is a quick snapshot of my rebased tree at the request of vagrantc.

There shouldn't be any functional changes.  If there are, that's cool too.

 gnu/system.scm | 28 +---------------------------
 1 file changed, 1 insertion(+), 27 deletions(-)

diff --git a/gnu/system.scm b/gnu/system.scm
index 23addf41e9..e32879b240 100644
--- a/gnu/system.scm
+++ b/gnu/system.scm
@@ -296,8 +296,7 @@ (define-record-type* <operating-system> operating-system
   (pam-services operating-system-pam-services     ; list of PAM services
                 (default (base-pam-services)))
   (setuid-programs operating-system-setuid-programs
-                   (default %setuid-programs)     ; list of <setuid-program>
-                   (sanitize ensure-setuid-program-list))
+                   (default %setuid-programs))    ; list of <setuid-program>
 
   (sudoers-file operating-system-sudoers-file     ; file-like
                 (default %sudoers-specification))
@@ -1203,31 +1202,6 @@ (define (operating-system-environment-variables os)
     ;; when /etc/machine-id is missing.  Make sure these warnings are non-fatal.
     ("DBUS_FATAL_WARNINGS" . "0")))
 
-;; Ensure LST is a list of <setuid-program> records and warn otherwise.
-(define-with-syntax-properties (ensure-setuid-program-list (lst properties))
-  (%ensure-setuid-program-list lst properties))
-
-;; We want to be able to use defines, so define a procedure.
-(define (%ensure-setuid-program-list lst properties)
-  (define warned? #f)
-
-  (define (warn-once)
-    (unless warned?
-      (warning (source-properties->location properties)
-               (G_ "representing setuid programs with file-like objects is \
-deprecated; use 'setuid-program' instead~%"))
-      (set! warned? #t)))
-
-  (map (match-lambda
-         ((? setuid-program? program)
-          program)
-         (program
-          ;; PROGRAM is a file-like or a gexp like #~(string-append #$foo
-          ;; "/bin/bar").
-          (warn-once)
-          (setuid-program (program program))))
-       lst))
-
 (define %setuid-programs
   ;; Default set of setuid-root programs.
   (let ((shadow (@ (gnu packages admin) shadow)))

base-commit: 21b718f4d6c3ded8ef50d12f6e9ae6474f74620f
prerequisite-patch-id: efc79914a4e3e994a8786e02774237de36f6b105
prerequisite-patch-id: 1986dc849c15ae6c1502df25f9c17b53a02df83d
prerequisite-patch-id: bb189cbd1346b0d00e9b79189155c9916731788b
prerequisite-patch-id: 062a02ed88acf0f11c5895b67065faa55d71fae8
prerequisite-patch-id: 2eea585e7940a16c24baeed3b65a123b1b10fd6b
prerequisite-patch-id: 31a3407b0c583d01cc2664168ec6cf499f10cb53
prerequisite-patch-id: a0566799f4aef296a3efcd228c3a223202662f86
prerequisite-patch-id: cd50cb9494a47433c7fd167729e239178c78d7f1
prerequisite-patch-id: e86e94b9a40613e3ce534ce778d027210b93b05a
prerequisite-patch-id: c7068d2079b3d2f0f172cc4cf9e0791ff5e84da3
prerequisite-patch-id: b52b35693094914ea1962ac2f186a52617d38c8a
prerequisite-patch-id: b2bdf5541825c9cd57d2fe3e3e9a90e5fc8ffbe6
prerequisite-patch-id: f085c8ee7c7f1d0250b0ed8a548a72d397d96056
prerequisite-patch-id: 49c8f3f912d24147362a3a874c2b2c0b4b182d5d
prerequisite-patch-id: 1f0fc1ca1a40444f4831beaf3183d7d4f866fd6d
prerequisite-patch-id: 8c69acfe3cb01ff3c0a46a2efe04b53ad063002d
prerequisite-patch-id: 10f972ac75020ce096d83b53a68a3b2f1eba1c8c
prerequisite-patch-id: 74586b82a25b775527adc7e8cf09b15bdb4850f7
prerequisite-patch-id: 7388ac8d395ef16830105026230e47d903026335
prerequisite-patch-id: 2c7df330bf50663218016e01b9c0922a6b3a001f
prerequisite-patch-id: f45ec5e6d6023fc5538e1578bbb4e270d7b23baf
prerequisite-patch-id: 0083d0b8d60fd0e526449cd192f153d0bd1bde0b
prerequisite-patch-id: 7e6e4ab87b52996e9bb6cd8595889f21ba87e9fe
-- 
2.41.0

[bug#61462] Add support for file capabilities(7)

[Vagrant Cascadian]

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

Thanks for the refreshed v2 patches! I gave them a quick spin...

As noted on IRC, apparently it lacks actual calls to setcap, so that
part still needs another patch at least!

Otherwise, it did seem to more-or-less work...

There are compatibility symlinks from /run/setuid-programs to
/run/privledged/bin and it sets setuid on requested files.

I was a little curious about why /run/privlidged/bin as opposed to
without /bin ... keeping the door open for other privlidged things? What
about things that come from /gnu/store/*/sbin ? are those handled any
differently?

My only concern is... wow is it hard, even for a native speaker, to
spell privileged!

live well,
  vagrant

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

[bug#61462] Add support for file capabilities(7)

[Vagrant Cascadian]

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

On 2023-07-21, Vagrant Cascadian wrote:
> Thanks for the refreshed v2 patches! I gave them a quick spin...
>
> As noted on IRC, apparently it lacks actual calls to setcap, so that
> part still needs another patch at least!
>
> Otherwise, it did seem to more-or-less work...
>
> There are compatibility symlinks from /run/setuid-programs to
> /run/privledged/bin and it sets setuid on requested files.

Oh, I noticed on reconfiguring back to a system without the patches to
support /run/privileged configurations ... the /run/privileged directory
is still present, with all those files sitting there in their previous
state.

This is why I think at least by default, many other distros implement
/run as a tmpfs or similar, so that it at least gets thrown out at
reboot. Though this is obviously a deeper problem than just this patch
series... I will file a separate bug about that.

live well,
  vagrant

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

[bug#61462] Add support for file capabilities(7)

[Ludovic Courtès]

Hey!

Vagrant Cascadian <vagrant@debian.org> skribis:

> Oh, I noticed on reconfiguring back to a system without the patches to
> support /run/privileged configurations ... the /run/privileged directory
> is still present, with all those files sitting there in their previous
> state.
>
> This is why I think at least by default, many other distros implement
> /run as a tmpfs or similar, so that it at least gets thrown out at
> reboot. Though this is obviously a deeper problem than just this patch
> series... I will file a separate bug about that.

We could try to make that change: /run as tmpfs, or wiped by
‘cleanup-service-type’.

Ludo’.

bug#64775: /run should be cleaned on boot

[brian via Bug reports for GNU Guix]

Vagrant Cascadian <vagrant@debian.org> writes:

> On 2023-08-08, Ludovic Courtès wrote:
>> We could try to make that change: /run as tmpfs, or wiped by
>> ‘cleanup-service-type’.
>
> Or both, really!
>
> Filed:
>
>   https://issues.guix.gnu.org/64775

I tried this a while ago, and the trivial case of mounting /run as tmpfs
in the operating-system definition causes errors during activation. It
turns out that the /run/current-system symlink is activated before all
non-root mounts, so mounting /run afterwards causes everything to break.

I don't have a solution, and haven't even looked at it past this, but
maybe this report will help.

-bjc