cvs commit: src/sys/ufs/ffs ffs_vfsops.c

[Robert Watson]

On Fri, 21 Apr 2006, Tom Rhodes wrote:

>>>  Remove what I believe are two useless ifdefs.  If a user or administrator
>>>  enables multilabel, or any option for that matter, most likely they have
>>>  a reason.  This will allow users to see that mulilabel is enabled via an
>>>  issued "mount" command and remove an annoying warning - printed only when
>>>  a MAC kernel is not installed - on boot up.
>>
>> This seems incorrect to me.  You have also removed the warnings associated 
>> with trying to use multi-label and ACL-enabled file systems on kernels not 
>> configured to support them, which can lead to highly undesirable behavior, 
>> hence the warnings.  The mount point flags are intended to reflect the 
>> current mode of operation, and setting the flags when the operational mode 
>> isn't supported doesn't seem right.
>
> Might I inquire to the "undesirable behavior" is?  When I was playing around 
> with this, I noticed no real effect, at least not in a negative way.

The way to think about it is as follows: there are actually three different 
flags for each of ACLs and multilabel:

- A flag in the superblock indicating administrator intent.  This is the one
   set by tunefs, and is persistent.

- A flag in the mount request indicating administrator intent.  This is -o
   acls or -o multilabel.

- A flag stored in the mount structure after mount, indicating run-time
   configuration.  This is what shows up in the mount output (acls) and
   (multilabel).

The first two have to do with what the administrator wants -- they want the 
file system to run with ACLs, or to run in multilabel mode.  The last one 
reflects run-time operation: the file system is, or is not, running with ACLs 
and multilabel.

A warning is generated when the administrator requests (via the superblock 
flag or mount flag) a run-time operation mode not supported by the current 
kernel.  The reason for this is that when a kernel has mounted a file system 
that requests a protection model that the kernel does not understand, the 
kernel is able to neither enforce those protections, nor maintain them.

The former is obvious: if your kernel is compiled without MAC support, it 
won't know how to interpret the security labels, and can't implement the 
protections described by them.

The latter is more subtle: when a kernel doesn't support ACLs or MAC, and the 
file system contains extended attributes holding ACLs and MAC labels, the 
contents of files, file system layout, and inode contents may change without 
the extended attributes being similarly updated.  This means that invariants 
normally maintained by the ACL and MAC code may no longer hold when they next 
run.  For example: the access ACL in POSIX.1e is actually a superset of the 
file ownership and some of the mode data.  The existing fields are maintained, 
and the "extended" ACL adds new fields with new interpretations.  If the 
system runs without ACLs enabled, the fields will get out of sync: the 
elements maintained in the permission bits and ownership field in the inode 
will reflect the most recent chmod(), but the elements in the extended 
attribute will be ignored.  Likewise, the default ACL: when ACLs aren't 
enabled, the default ACL is simply not implemented, so files and directories 
created while the file system is mounted without kernel support will not have 
the intended protections.  The system won't (shouldn't) panic, but you'll get 
some very confusing results when you start running with ACLs again and the 
protections on files appear not only to have changed from the run without 
ACLs, but you may have ACLs on files that are neither the permissions set 
during that run, nor the complete ACLs present on the previous run.

You can imagine a lot of bad things happening -- backups being taken or 
restored losing their proper protections, etc.  The warnings are present to 
help prevent exactly that: if the administrator has enabled ACLs, and then 
taken ACL support out of the kernel, they will get a warning at mount time. 
Likewise, if the file system is marked as having MAC labels on objects, and 
MAC isn't compiled in, we generate a warning.  I thought about not letting the 
mount proceed, but for recovery purposes, that's a problem, because not being 
able to mount your root file system or tools to build a kernel isn't good! 
This was as close as we could get without significantly reducing the 
robustness of the system in the face of administrator failure.

> These are the reasons I made this change, and you have an email from me 
> about this too:

Sorry about not responding to that e-mail in a timely manner -- I've been on 
international travel for the last two weeks, and have responded to very little 
e-mail in a timely manner during that trip :-).

> 1: If I change the newfs flags while installing FreeBSD, I would
>   think I have a clear reason for adding "-l."

Yes, one would hope.

> 2: A standard "mount" command does not show multilabel enabled until
>   a MAC kernel is installed.  Most likely if I enabled it, I plan
>   to build a kernel.

Tunefs should show the flag set, showing the intent, but mount should not, 
since the file system is not, in fact, mounted multilabel.  Multilabel, as 
with ACLs, is a run-time condition reflecting the behavior of the file system, 
not the administrator intent for the file system.

> 3: The correct fix would be to offer a MAC kernel in sysinstall,
>   similar to how Linux offers one to enable or disable SELinux
>   (seen with Redhat and CentOS installs).

This is, in fact, the reason that we have not modified the base system 
sysinstall to be able to set the multilabel flag as part of the UI.  Since 
there's no default built kernel with MAC in the install environment, allowing 
the multilabel flag to be set during install can only result in warnings and a 
lack of implementation of the requested feature.  In the SEBSD development 
branch, we do support installing a MAC kernel, and there is a menu option to 
set multilabel.

But this is not a fix for the underlying problem that you have introduced: the 
mount-time warnings and mount output are intended to reflect the current 
configuration, and help the administrator decide that the system is 
incorrectly configured.

> 4: With regards to number 2, I think the option should at least
>   be spit out with all other options when using mount(8) to
>   review file system information

The problem you're running into is the difference between requested settings 
for a file system, and applied settings.  The warning on the console is 
intended to help distinguish those two: if you request a setting that cannot 
be applied, you get a warning when the file system is mounted.

> I'll revert it if you feel strongly about it; however, I want it to be known 
> what my opinion is.  And I find the warnings extremely annoying and have 
> answered at least one question as to why "mount don't show me correct 
> output."  Yes, real quote.  :)

If MAC support isn't compiled into the kernel, MAC isn't going to work, so the 
fact that 'multilabel' doesn't show up in the mount output is a relatively 
minor failure mode.  However, the warning it generates is key to diagnosing 
the problem, and you have removed the warning.  Two classes of warnings should 
be generated on the console when MAC isn't compiled in:

- Warnings that policy modules cannot be loaded due to missing MAC support.

- Warnings that the file system is configured for MAC (multilabel) but MAC
   isn't compiled in.

If the administrator requests multilabel support but the file system doesn't 
enable it, then the diagnosis path should be to look to see why.  In 
particular, to look at the output from the mount process, which until your 
change, clearly indicated why there was a failure.  In general, I recommend 
doing "dmesg | grep -i mac" when there appears to be a problem, as that should 
pull out the above to warnings.  You can then, per my advice on IRC, use mount 
and tunefs to inspect the current run-time and requested mount behavior, in 
order to observe that they differ.

Robert N M Watson