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#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

bug#64775: /run should be cleaned on boot

[Ludovic Courtès]

Hi,

Vagrant Cascadian <vagrant@debian.org> skribis:

> On 2023-08-08, Ludovic Courtès wrote:
>> 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’.
>
> Or both, really!
>
> Filed:
>
>   https://issues.guix.gnu.org/64775

This went unnoticed but here’s a patch:

  https://issues.guix.gnu.org/72920

I’ll apply it soon if there are no objections.

Ludo’.