extattr in-kernel interface

[Ilmar S. Habibulin]

On Tue, 18 Apr 2000, Robert Watson wrote:

> I hope to have some example code in the form of the capability stuff in a
> day or two.  In the mean time, take a look at extattr(9),
> VOP_GETEXTATTR(9) and VOP_SETEXTATTR(9) which should all be available as
> of 4.0-RELEASE.  The SETEXTATTR call requires a lock to be held on the
> vnode. 
> Also, you can take a look at the syscall interface exposed to userland--it
> can be found in src/sys/kern/vfs_syscalls.c, towards the bottom.  The
Ohhh, as i understand, i have to copy all set/get_extattr code. :(
And what about your idea about user-only/kernel-only modifiable
attributes? I don't see any hooks in code.

> I'll be committing man pages for the syscalls in a week or two, most
> likely.  The syscall semantics were discussed some when I first proposed
> the interface on freebsd-arch around December, but for some reason I
> neglected to convert the proposal into man pages for the syscalls
> (although all the VOP's went in).  The syscalls, needless to say,
> demonstrate the use of the calls from userland.  To do so in kernel will
> require you to set up the appropriate aio structures pointing to the data
> you want to read/write in kernel, and then call the VOP_'s, much the same
> as calling the normal VOP_WRITE and VOP_READ routines.
That's a puty. I'd like to have something more easy to use, without this
uio/iovec stuff. Is it too hard to make some generic in-kernel function,
which will took some buffer pointer with buffer length and an attribute
name as params?

> One thing that does need to be decided is whether or not to include MAC
> labeling and capability flags at the VFS layer, or whether it's
> easier/more appropriate to instead have those semantics be imposed by the
> code that sits on top of VFS, which would just use extended attributes to
> retrieve data.  Certainly in the short term, directly accessing the data
> via the extended attribute calls makes sense--however, abstracting that
> retrieval is also a good idea :-).
I think that CAPs, MAC labels, etc should be on top of VFS code. They are
just an attributes of the file. The point is how to get and use them, who
would do this - kernel or user-space application. Again question about
user/kernel modifiable attributes. Have you took a look at ob1 sgi project
source code? Interesting stuff, i say. ;-) But i don't understand their
network MAC implementation. Have no time to dig dipper right now.

> I've been participating in some discussion on the Linux ACL developers
> mailing list concerning extended attribute semantics, and implementation
> issues, and will attempt to summarize that discussion here once it's
> wrapped up a bit.  We're interested in developing a consistent API across
> platforms if they decide to go the extended attribute route for backing
> ACL data for inodes.  It sounds like they are quite interested in that
> option at this point, but will probably modify the filestore to link
> attributes to inodes, rather than using backing files.  This has a number
> of advantages (performance, consistency, flexibility)--on the other hand,
> it continues to require that the base file system be modified, imposing
> substantial development costs, and lowering the chances of integration
> with the base file system.  In the long term, I see us moving in the same
> direction, but the current extended attribute backing mechanism works and
> allows us to make forward progress.  If we can develop a consistent API
> addressing all the requirements of both storage models, that would be the
> best of both worlds :-).

I have no objection on userland API. MAC should use only a part of it or
not. I don't deside how to create backing files, when, how, who should
create them.

PS. Do you still plan to use rwx model for ACLs?

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