CAPs, MACs, ACLs, FreeBSD implementation

[Ilmar S. Habibulin]

On Fri, 1 Oct 1999, Robert Watson wrote:

> On Fri, 1 Oct 1999, Ilmar S. Habibulin wrote:
> 
> > can't (on-disk inode i mean). So we have to create new fs - that's no a
> > good solution, imho. I offer the following approach - in the inode
> > structire we have 2*sizeof(int32_t) bytes, that we can use as a pointer to
> > some disk block containing MAC labels, Capabilities, ACLs, Information
> > Labels and so on. The same thing i think we should do with the proc
>
> I posted a summary of some of the FS supporting options for ACLs to the
> FreeBSD list yesterday evening--I'll forward a copy here also.  It
I've read it.

> basically came down to the fact that the infrastructure for easy file
> system modification isn't there.  Your best bet may be to build the
> process infrastructure and syscalls, and for the time being avoid the disk
That's not the problem. The problem is interconnection between on-disk
info, in-kernel-memory-info and in-user-memory-info. Building
infrastructure is the first step, that i maid while implementing MAC.
To ALL: my implementation is bad and wrong. I should remake it. ;-)

> state issue.  As mentioned previously, the Linux people have the same
> problem with finding a place to store their state.  With both ACLs and
> Capabilities, you can still address some of the architectural
> issues--presumably the VFS needs to updated with some additional calls
> against vnodes, which for the time being will not be implemented by the
> standard file systems.
I don't know how to answer you right now. MACs and CAPs are easy to
implement separately. But there is no space in the inode to store all the
necessary attributes. But there is _reserved for future use_ (unused) 8
bytes of space. Why not to use my proposal? I'll read about userfs and
layers, but i do not trust this approach, maybe because of my lack of
knowledge.

> A good candidate for testing file systems is MFS--your changes don't get
> preserved and you don't have to fix fsck to deal with the mess you make.
> However, I believe MFS shares a lot of data structures with FFS--this will
> need to be fixed first.
To my surprise, then i tried to modify mfs to support MAC, i've found out
that there is no change needed.

> Probably the easiest way to get support in there is to write a userland
> layer based on one of the several available userfs implementations.  Both
> Coda and Arla provide (fairly heavy-duty) userfs support.  There's also
> portalfs as an example, and some people have used local NFS (i.e.,
> sharity, etc).  None of these are really ideal, but Arla's kernel module
> is fairly clean and supports parallelism.
To ALL: Do some one whats to write code?
I''ll try to understand how it works and maybe work out some proposal of
freebsd posix userfs, but "two head are better than one". ;-)


To Unsubscribe: send mail to majordomo at cyrus.watson.org
with "unsubscribe posix1e" in the body of the message