ACL support.

ACL support.

[pelletierma]

Hello,

I've given a swing at ACL support for the linux kernel.  Kernel patches and userland support is avaliable for review at

http://sourceforge.net/projects/linux-acl/

I'm looking for complaints, praise, suggestions, and bug reports.  :-)  Since I'm unfamiliar with non-i386 entry.S, I've not yet added the system calls to other architectures, though.  Sorry.

I'm on a slow link, so I can't subscribe to the mailing list and remain sane simultaneously.  Please cc: comments to me; or post on the sourceforge project forums.

If you people think this is a Bad Idea(tm) to begin with, just tell me.  :-)

-- Marc A. Pelletier

-- Original annoucement follows --

Initial release of Linux ACL support.

Somethings to dig your security teeth into: ACL support for the Linux kernel.

Access Control Lists allow fine grained access control to filesystem objects, by attaching a list of permissions to grant or deny specific capabilities to users or groups.
This implementation of ACL for the Linux kernel provides semantics that are almost totally compatible with the traditional POSIX umode model for applications that are unaware of the kernel support.

Features include the ability to set rights for fine grained operation on filesystem objects (such as separate write/truncate/append permissions) to an arbitary number of users or groups; and the ability to "offer" a file for chown()ing by another user.

Currently, using the package requires patching and recompiling your kernel, and installing tools to use the new features, thus requiring some kernel-fu savvy.

Once development has reached a stable, reliable state and has been well tested, the kernel patch aspect will be submitted for inclusion in the main kernel sources.

Testers are welcome, and peer review of the security aspects of the code are welcome, and desired.


-- 




__________________________________________________________________
Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/

Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/

Re: ACL support.

[Andreas Dilger]

On Mar 05, 2002  15:32 -0500, pelletierma@netscape.net wrote:
> I've given a swing at ACL support for the linux kernel.  Kernel patches
> and userland support is avaliable for review at
> 
> http://sourceforge.net/projects/linux-acl/

Please see http://acl.bestbits.at/ - this has been added to the 2.5 kernel
already, and has existed for a long time now...

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/

Re: ACL support

[Andreas Dilger]

On Mar 07, 2002  15:58 -0500, pelletierma@netscape.net wrote:
> In response to a number of email I have received, I wanted to make
> something clear:  I'm not out to compete with the bestbit implementation of 
> ACLs over extended file attributes.  :-)
> 
> What I am offering is an alternative implementation of ACL support at the
> VFS level, that remains independent of filesystem support for ACLs.

Then you must not have looked at the bestbits.at code at all.  It includes
a generic VFS interface for EAs and ACLs.  There are ext2, ext3, and XFS
codes which work with this VFS interface.

Some people have had complaints about the bestbits VFS interface, and
another one for people to look at is never a bad thing.

Cheers, Andreas
--
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert

Re: ACL support

[pelletierma]

Hello.

In response to a number of email I have received, I wanted to make
something clear:  I'm not out to compete with the bestbit implementation of 
ACLs over extended file attributes.  :-)

What I am offering is an alternative implementation of ACL support at the
VFS level, that remains independent of filesystem support for ACLs.  In
fact, my patch provides filesystem support for ramfs only at this time
(which was ideal for testing).

The extenteded attribute system as implemented is very good (and in fact
I am using it for a project of mine), and provide an excellent
infrastructure for implementing ext2 and ext3 support for ACL...  only
I beleive that providing an uniform interface and evaluation of ACLs that
remains independent of the filesystem is the Right Thing(tm).

Placing ACLs at the VFS level also allows subdivision of the traditional
rwx semantics.  In fact, people emailed me after testing my patch have
suggested additional subdivisions of access right that would be useful
for some other non persistent filesystems (proc and devfs) such as
giving a bit for ioctl()s.  And since my ACL system is based on VFS
inodes, it can be extended to sockets as well, which would make useful
connection and listen permissions, for instance.
I have not touched implementation of ACL for ext2 and ext3 yet /exactly/
because the bestbits extended attributes existed, and I felt the people
working on that code would be in an excellent position to interface with
my ACL support seamlessly.

Both codebases can be viewed as orthogonal, not competing.  That's the
way I chose to look at it, and I hope others can feel the same as well.

Happy coding.  :-)

-- Marc A. Pelletier

-- 




__________________________________________________________________
Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/

Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/