[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Extended Attributes and Access Control Lists


On Thu, Nov 01, 2001 at 09:28:51PM -0700, Peter J. Braam wrote:
> I'd like to just add my 2 cts worth to this:
>  - sharing ACL's: for distributed file systems this is actually really
>  useful since it means that a server could compute capabilities for a
>  client based on the ACL id rather than doing it again and again which
>  leads to efficient distributed authorization.

Again, this brings up the problem of _where_ the different ACL
API/ABIs live in the stack.

If you want generic syscalls to access ACLs, then those syscalls
cannot be expressed in terms of independent ACL cookies --- there
already exist distributed filesystems which don't use cookies for
their ACLs.

If you are building the distributed filesystem on top of a specific
local filesystem which exposes ACL sharing directly, _then_ it might
be possible to do this.  Or, if you build your distributed
filesystem's ACL mechanisms out of low-level generic EAs, you can
implement the sharing yourself in the higher levels.  But the primary
kernel ACL API really needs to support ACLs which are not necessarily

>  - if you are building an inode v2 I have two wishes: store i_version
>  on the disk and store the parent ino on the disk for
>  directories. Both can considerably simplify file servers like knfsd

We do.  i_generation is held on disk in the inode, and ".." is in the
first directory data block (not in the inode, but still easy to get to
from within the filesystem, and it's always updated correctly on
things like directory rename).  It's actually much harder to get at
the ".." if you go throught the VFS, though.

>  - I am working with folks that will likely want to have EA's bigger
>  than a block to store versioning information.  We have discussed
>  implementing such EA's by building a directory (or directory tree ala
>  squid) with lots of files each of which represents the EA for the
>  inode given by the filename.

For unbounded extra info like that, it's probably better to go the
route of extra data forks rather than an EA implementation.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]