PERFORCE change 5980 (fwd)

[Robert Watson]

For those running the MAC code from cvsup10, a recent change (description
forwarded below)  requires that 'multilevel' be stuck in /etc/fstab beside
each UFS filesystem that will be using EAs to support MAC labels.  Example
entry:

/dev/ad0s1e     /mnt    ufs     rw,multilevel      0       0

Only when that flag is present will the UFS code attempt to use EAs to
support labels; if the flag is not present, the entire filesystem will be
treated as a single object with a single MAC label.  This flag can be
changed at run-time, but due to the cache coherency bug identified below,
it should be used only for upgrades to multilevel, and not downgrades, for
the time being.  Setting multilevel on filesystems that do not support it
will have no effect (eventually, should be rejected).  This change makes
clear the difference between "EA storage was available for labels" and
"Labels should be stored in EAs".  It might eventually be desirable to
make this a per-fs flag in the file system header, or provide some sort of
media-based configuration, but this works fine for now.

The diskless boot scripts have been updated to set multilevel support on
/var and /tmp appropriately.  They will be modified to also set multilevel
support on /etc shortly. 

Robert N M Watson             FreeBSD Core Team, TrustedBSD Project
robert at fledge.watson.org      NAI Labs, Safeport Network Services

---------- Forwarded message ----------
Date: Tue, 29 Jan 2002 12:52:04 -0800 (PST)
From: Robert Watson <rwatson at FreeBSD.org>
To: Perforce Change Reviews <perforce at freebsd.org>
Subject: PERFORCE change 5980 for review

http://people.freebsd.org/~peter/p4db/chv.cgi?CH=5980

Change 5980 by rwatson at rwatson_tislabs on 2002/01/29 12:51:55

	Add support for MNT_MULTILEVEL, a filesystem flag to indicate
	whether filesystems with support for per-object MAC labels should
	use them or not:
	
	o Generally introduce MNT_MULTILEVEL all over the place, including
	  mount.h, userland mntopts.h and mount.c.  This takes the value
	  of MNT_SPARE2, which leaves us with one spare.  Hope that nmount()
	  is done soon.
	
	o Always set the flag in the devfs mount routine, since devfs
	  currently always runs multi-level.  Adding single-level support
	  would be easy, but we can't think of a reason to do that.  It can
	  be added if needed.
	
	o Modify UFS so that it checks MNT_MULTILEVEL in the mount flags
	  before performing getlabel and setlabel.  If false, do
	  vop_stdgetlabel() for ufs_getlabel(), and for ufs_setlabel(),
	  return EOPNOTSUPP.  Otherwise, use existing logic to use cached
	  vnode copy, or go to extended attributes.
	
	o Restrict new label management for ufs_makeinode() and ufs_mkdir()
	  to the multi-level case, since it's not needed for single-level.
	
	o Make the ufs_pathconf() implementation simply test the flag.
	  Note that this isn't quite as material as the old EA check, but
	  is maybe more correct.
	
	NOTE: Right now, cached values are not flushed when switching
	from single to multi-level.  This means that if the attribute
	files are tweaked after down-grading to single-level, and then
	an upgrade to multi-level occurs, you will get the old labels.
	This will be fixed at some point, possibly using a generation
	number of walking the file system's vnode list.  A temporary
	fix might forbid downgrade.
	
	NOTE: When multi-level, if label setting on a new object fails,
	then the creation is allowed to succeed with a console warning,
	and the object uses the default label.  This should result in a
	failure, eventually.

Affected files ...

... //depot/projects/trustedbsd/mac/sbin/maccontrol/Makefile#1 add
... //depot/projects/trustedbsd/mac/sbin/mount/mntopts.h#2 edit
... //depot/projects/trustedbsd/mac/sbin/mount/mount.c#2 edit
... //depot/projects/trustedbsd/mac/sys/fs/devfs/devfs_vfsops.c#3 edit
... //depot/projects/trustedbsd/mac/sys/sys/mount.h#4 edit
... //depot/projects/trustedbsd/mac/sys/ufs/ufs/ufs_vnops.c#19 edit

Differences ...


To Unsubscribe: send mail to majordomo at trustedbsd.org
with "unsubscribe trustedbsd-discuss" in the body of the message