Date: Wed, 27 Nov 2002 14:37:16 -0500 (EST) From: Robert Watson <rwatson@FreeBSD.ORG> To: Bruce Evans <bde@zeta.org.au> Cc: bsdc@xtremedev.com, Hiten Pandya <hiten@angelica.unixdaemons.com>, current@FreeBSD.ORG Subject: Re: ACLs on the boot partition? Message-ID: <Pine.NEB.3.96L.1021127143405.50233C-100000@fledge.watson.org> In-Reply-To: <20021128060920.N9287-100000@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 28 Nov 2002, Bruce Evans wrote: > On Wed, 27 Nov 2002, Robert Watson wrote: > > > On Wed, 27 Nov 2002, Bruce Evans wrote: > > > > > On Tue, 26 Nov 2002, Robert Watson wrote: > > > > > > > tunefs changes the flag for the next mount, so doesn't take immediate > > > > effect. Once you've tunefs'd a read-only file system, you need to unmount > > > > and remount it -- for the file system root, this generally means > > > > rebooting. Just to confirm: you're running with GENERIC, or with a kernel > > > > > > Er, what is the mount(..., MNT_RELOAD ...) in tunefs for then? > > > > The problem is that some flags can't be changed via MNT_RELOAD and require > > a from-scratch mount. I'm hoping that with nmount(), we can get a little > > more expressive regarding what changes are (and aren't) allowed to flags. > > Right now there's some uncomfortable masking. > > Why can't they be changed? All the other tunefs flags except FS_ACLS > and FS_MULTILABEL are related to writing, so ffs_reload() has to support > them changing as a side effect of supporting transitions from read-only > to read-write mode. Switching ACLs to support a change shouldn't be a problem, although I'd generally discourage changing the ACLs flag very much, since you don't want inconsistent access control and other side effects of using ACLs inconsistently (they get out of sync, etc). Multilabel can't be changed because of cache coherency issues: we cache label data in the vnode, and changing the origin of the label data (what MNT_MULTILABEL effectively does) would invalidate the contents of the cache. To correct that, we'd have to support immediately (and atomically) walking the entire vnode list and re-loading and validating the labels, something that we don't currently do. There are some bugs in the UFS1 extended attribute implementation relating to the remount issue, actually -- in particular, the EA backing files for UFS1 are opened read-write, and UFS blocks an upgrade from read-only to read-write if they are read rather than read-only. We need to force a re-open of the backing files and make the flags passed to open/close match that. I suspect the quota code must already have that behavior. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1021127143405.50233C-100000>