GNU bug report logs - #51425
Invalid <file-system> flags lead to a crash when booting

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 51425 in the body.
You can then email your comments to 51425 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jonathan Brielmaier <jonathan.brielmaier <at> web.de>
To: bug-guix <at> gnu.org
Subject: file-system: validate flags
Date: Wed, 27 Oct 2021 00:24:28 +0200

Imagine the following file system definition in your config.scm:

```
(file-system
  (device (uuid "UUID-123"))
  (flags '((create-mount-point? #t)))
  (mount-point "/mnt")
  (type "ext4")))
```

When you reconfigure there will be no complain, but when you reboot your
system wont boot. The parameter to flags is nonsense, it should be
something like: `read-only`. So mounting of the file system will fail...

It would be nice if we can have some flag validation during reconfigure.

~Jonathan

Message #8 received at 51425 <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Jonathan Brielmaier <jonathan.brielmaier <at> web.de>
Cc: 51425 <at> debbugs.gnu.org
Subject: Re: bug#51425: file-system: validate flags
Date: Wed, 27 Oct 2021 21:31:35 -0400

Hello,

Jonathan Brielmaier <jonathan.brielmaier <at> web.de> writes:

> Imagine the following file system definition in your config.scm:
>
> ```
> (file-system
>   (device (uuid "UUID-123"))
>   (flags '((create-mount-point? #t)))
>   (mount-point "/mnt")
>   (type "ext4")))
> ```
>
> When you reconfigure there will be no complain, but when you reboot your
> system wont boot. The parameter to flags is nonsense, it should be
> something like: `read-only`. So mounting of the file system will fail...
>
> It would be nice if we can have some flag validation during reconfigure.
>
> ~Jonathan

I agree that it'd be nice; I had gotten close to implementing such a
thing in the past, but it was discussed and abandoned because each file
system may have their own flags, add new flags with new releases, etc,
which means it'd be difficult to keep the list accurate.

That's if my memory serves me right :-).

Thanks,

Maxim

Message #11 received at 51425 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Jonathan Brielmaier <jonathan.brielmaier <at> web.de>
Cc: 51425 <at> debbugs.gnu.org, Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Subject: Re: bug#51425: file-system: validate flags
Date: Fri, 29 Oct 2021 21:13:40 +0200

Hi!

Jonathan Brielmaier <jonathan.brielmaier <at> web.de> skribis:

> Imagine the following file system definition in your config.scm:
>
> ```
> (file-system
>   (device (uuid "UUID-123"))
>   (flags '((create-mount-point? #t)))
>   (mount-point "/mnt")
>   (type "ext4")))
> ```
>
> When you reconfigure there will be no complain, but when you reboot your
> system wont boot.

I suppose it fails to boot because of a match error in
‘mount-flags->bit-mask’, right?

> The parameter to flags is nonsense, it should be something like:
> `read-only`. So mounting of the file system will fail...

That’s a good use case for the recently-added ‘sanitize’ record field
property.

Ludo’.

Message #14 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Tobias Geerinckx-Rice <me <at> tobias.gr>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>, Ludovic Courtès <ludo <at> gnu.org>
Cc: 51425 <at> debbugs.gnu.org, bug-guix <at> gnu.org,
 Jonathan Brielmaier <jonathan.brielmaier <at> web.de>
Subject: Re: bug#51425: file-system: validate flags
Date: Fri, 29 Oct 2021 21:41:15 +0200

[Message part 1 (text/plain, inline)]

[FTR, I'm the one who encouraged Jonathan to file a bug.  Mount 
flags seem ideally suited to build-time validation.]

Maxim,

Maxim Cournoyer 写道：
> each file system may have their own flags

Really?  Huh.  Interesting.  How does that work?  Where would 
these file-system specific flags be #defined?

(My guess is that if anyone does this, it'd be ZFS ;-)

> add new flags with new [Linux] releases

Well, sure, but then we simply add them to Guix.  This applies to 
everything from syscalls to services.

Ludo', I'll take a look at ‘sanitize’; thanks!

Kind regards,

T G-R

[signature.asc (application/pgp-signature, inline)]

Message #20 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Tobias Geerinckx-Rice <me <at> tobias.gr>
Cc: Ludovic Courtès <ludo <at> gnu.org>, bug-guix <at> gnu.org,
 51425 <at> debbugs.gnu.org, Jonathan Brielmaier <jonathan.brielmaier <at> web.de>
Subject: Re: bug#51425: file-system: validate flags
Date: Fri, 29 Oct 2021 20:45:28 -0400

Hello Tobias,

Tobias Geerinckx-Rice <me <at> tobias.gr> writes:

> [FTR, I'm the one who encouraged Jonathan to file a bug.  Mount flags
> seem ideally suited to build-time validation.]
>
> Maxim,
>
> Maxim Cournoyer 写道：
>> each file system may have their own flags
>
> Really?  Huh.  Interesting.  How does that work?  Where would these
> file-system specific flags be #defined?

Or maybe I'm confusing with file system options; I can't find the past
discussion that I had on mind; but options are file driver specific,
while flags are file system independent.  So yes, flags are a good
candidate for validation!

Another thing that is tricky about options is that some of them are only
really understood by the 'mount' command line utility, not the 'mount'
system call such as used in our init RAM disk (both are thrown together
in 'man 8 mount' without an easy way to discern them apart, IIRC).

> Ludo', I'll take a look at ‘sanitize’; thanks!

Neat, thank you Tobias!

Maxim

Message #26 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Tobias Geerinckx-Rice <me <at> tobias.gr>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: Ludovic Courtès <ludo <at> gnu.org>, bug-guix <at> gnu.org,
 51425 <at> debbugs.gnu.org, Jonathan Brielmaier <jonathan.brielmaier <at> web.de>
Subject: Re: bug#51425: file-system: validate flags
Date: Sat, 30 Oct 2021 02:48:50 +0200

[Message part 1 (text/plain, inline)]

Maxim,

Maxim Cournoyer 写道：
> Another thing that is tricky about options is that some of them 
> are only
> really understood by the 'mount' command line utility, not the 
> 'mount'
> system call such as used in our init RAM disk (both are thrown 
> together
> in 'man 8 mount' without an easy way to discern them apart, 
> IIRC).

Aha!  Let me introduce you to the only slightly unfortunately 
named ‘man 2 mount’ instead.

The way mount(8) lumps both together is… I guess it's 
user-friendly — in a way? — but it leads to this total confusion 
about what's what.  Think of flags as literal bit flags, mainly 
because they are.

Guix does make the distinction.  It's the right call but it leads 
to a brief education moment the first time you encounter both 
fields.

You're absolutely right that mount options OTOH are arbitrary 
strings.  They can't and shouldn't be ‘validated’, but we don't 
currently mandate their stringiness, and should.

Kind regards,

T G-R

[signature.asc (application/pgp-signature, inline)]

Message #32 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Tobias Geerinckx-Rice <me <at> tobias.gr>
Cc: Ludovic Courtès <ludo <at> gnu.org>, bug-guix <at> gnu.org,
 51425 <at> debbugs.gnu.org, Jonathan Brielmaier <jonathan.brielmaier <at> web.de>
Subject: Re: bug#51425: file-system: validate flags
Date: Sat, 30 Oct 2021 22:31:40 -0400

Hi Tobias,

Tobias Geerinckx-Rice <me <at> tobias.gr> writes:

> Maxim,
>
> Maxim Cournoyer 写道：
>> Another thing that is tricky about options is that some of them are
>> only
>> really understood by the 'mount' command line utility, not the
>> 'mount'
>> system call such as used in our init RAM disk (both are thrown
>> together
>> in 'man 8 mount' without an easy way to discern them apart, IIRC).
>
> Aha!  Let me introduce you to the only slightly unfortunately named
> ‘man 2 mount’ instead.

Eh, I'm not sure why I hadn't thought about that myself, thank you!  It
makes sense after all -- one man page (2) documents the options for the
system call, the other one (8) for the command.

> The way mount(8) lumps both together is… I guess it's user-friendly —
> in a way? — but it leads to this total confusion about what's what.
> Think of flags as literal bit flags, mainly because they are.

Hehe.

> Guix does make the distinction.  It's the right call but it leads to a
> brief education moment the first time you encounter both fields.
>
> You're absolutely right that mount options OTOH are arbitrary strings.
> They can't and shouldn't be ‘validated’, but we don't currently
> mandate their stringiness, and should.

Makes sense.

Thank you!

Maxim

Message #42 received at 51425-done <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Jonathan Brielmaier <jonathan.brielmaier <at> web.de>
Cc: 51425-done <at> debbugs.gnu.org, Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Subject: Re: bug#51425: file-system: validate flags
Date: Sun, 07 Nov 2021 23:16:17 +0100

Hi,

Ludovic Courtès <ludo <at> gnu.org> skribis:

> Jonathan Brielmaier <jonathan.brielmaier <at> web.de> skribis:
>
>> Imagine the following file system definition in your config.scm:
>>
>> ```
>> (file-system
>>   (device (uuid "UUID-123"))
>>   (flags '((create-mount-point? #t)))
>>   (mount-point "/mnt")
>>   (type "ext4")))
>> ```
>>
>> When you reconfigure there will be no complain, but when you reboot your
>> system wont boot.
>
> I suppose it fails to boot because of a match error in
> ‘mount-flags->bit-mask’, right?
>
>> The parameter to flags is nonsense, it should be something like:
>> `read-only`. So mounting of the file system will fail...
>
> That’s a good use case for the recently-added ‘sanitize’ record field
> property.

Done in 5eb5c0789f34e87ee417a53ddfcfa3b6521bb337.

Thanks,
Ludo’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.