cvs commit: src/sys/ufs/ffs ffs_vfsops.c
rwatson at FreeBSD.org
Sat Apr 22 12:39:14 UTC 2006
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
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
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
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
> 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
More information about the cvs-src