Date: Sat, 22 Apr 2006 13:38:59 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Tom Rhodes <trhodes@FreeBSD.org> Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/ufs/ffs ffs_vfsops.c Message-ID: <20060422131358.F56433@fledge.watson.org> In-Reply-To: <20060421212322.2f5b3fa8.trhodes@FreeBSD.org> References: <200604210714.k3L7EQhD046878@repoman.freebsd.org> <20060421161321.J44089@fledge.watson.org> <20060421212322.2f5b3fa8.trhodes@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060422131358.F56433>