going to commit (was: Re: file system extended attributes support)

Robert Watson robert at cyrus.watson.org
Fri Apr 14 17:32:01 GMT 2000


I sent this out a few days ago, and have thus far received only postive
comments.  With this in mind, I'm going to go ahead and commit the FFS
extended attribute support to 5.0-CURRENT this evening, modulo the
following changes --

1) clean up debugging output

2) possibly have the various baby extattr tools be a single binary that
   checks argv[0]

Are there, at this point, any objections to my committing, or suggestions
as to improvements that should be made?

Just as a recap: enabling of extended attributes is toggled by the
FFS_EXTATTR kernel option, and following that, it must be 1) started for
each fs to be used, and 2) specific extended attributes must be
explicitely enabled.  Current this is done using the extattrctl utility,
although I'm contemplating pushing some management info into /etc/fstab as
with quotas, or having a startup script that auto-starts attributes in the
/.attributes directory on each fs.  Auto-starting will wait until I've
seen more broad testing with it in the code base.

Robert

On Mon, 10 Apr 2000, Robert Watson wrote:

> As part of the supporting code base for a number of security-related
> projects on FreeBSD, I've hacked up extended attribute support for
> FreeBSD.  This allows arbitrary named attributes to be associated with
> each inode, maintained by the kernel.  In December, I committed APIs
> associated with this code to the FreeBSD repository, and now after a few
> months of testing and use, I'd like to commit the code itself to the repo.
> Doing so will facilitate the further development of a number of
> security-related projects, including the TrustedBSD MAC, ACL, and
> Capability support, as well as third party security code such as the
> NAI/TIS Labs FreeDTE code.
> 
> This code is similar to the Quota code, in that it stores attributes in
> backing files in the file system (or in another file system), and may be
> enabled per-FFS partition.  My feeling is that this approach allows
> maximum flexibility at this point in the life cycle of FreeBSD in terms of
> VFS maturity.  As the support for stacked file systems matures, I'd be
> willing to reconsider the manner in which this is implemented.
> 
> The current version of the code, diff'd from the main repo a few days ago
> on the 5.0-CURRENT (head) branch, is available for download at:
> 
> 	http://www.trustedbsd.org/downloads/
> 
> It contains a great deal of #ifdef'd debugging code, but also contains
> some utilities that can be experimented with.  I recommend reading the
> extattrctl man page first.  The excessive debugging code will be stripped
> before committing, and once I'm confident that it works for more than just
> the four or five people who've used it thus far :-).
> 
> Thanks,
> 
>   Robert N M Watson 
> 
> robert at fledge.watson.org              http://www.watson.org/~robert/
> PGP key fingerprint: AF B5 5F FF A6 4A 79 37  ED 5F 55 E9 58 04 6A B1
> TIS Labs at Network Associates, Safeport Network Services
> 
> 
> 
> To Unsubscribe: send mail to majordomo at FreeBSD.org
> with "unsubscribe freebsd-fs" in the body of the message
> 


  Robert N M Watson 

robert at fledge.watson.org              http://www.watson.org/~robert/
PGP key fingerprint: AF B5 5F FF A6 4A 79 37  ED 5F 55 E9 58 04 6A B1
TIS Labs at Network Associates, Safeport Network Services

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



More information about the trustedbsd-discuss mailing list