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

Re: Proposal: /etc /usr/etc /usr/local/etc

Vadim Vygonets writes:
 > On Fri, 4 Jul 1997, Yann Dirson wrote:
 > > About ACL's: they seem to be planned since quite a long time, but
 > > there is still not much code supporting them in 2.1.43 kernel. I think
 > > I'll have to mail Remy Card to find out about that; it could help much.
 > I really don't know what ACL is.

Oops, sorry :) You're really misig something, here. ACL stands for
Access Control List. An ACL is a list of statements like
'(user.group):perms', where 'perms' is [r][w][x] which gets associated
to an inode, giving 'perms' access permissions to 'user.group'. With
ACL's, you can control file-access more finely than with the standard
user/group/others scheme. Basically, a setting of 0754, for example,
would yield an ACL of: '(user.%):7, (%.group):5, (%.%):4'. You may add
any other access-control items with 'chacl', and list them with
'lsacl'. HP/UX-9 adds a '+' just after standard perms in 'ls -l'
output to signify there are ACL's on a file's inode.
[ACL syntax in my example is inspired by HP/UX syntax, but YMMV]

AFAIK, Remy Card (e2fs' author) has worked on implementing these in
ext2, but I have no idea about its current status. There are many
references to ACLs in kernel include files, and a 'acl.c' file in
linux/fs/ext2, but it doesn't contain much.

 > >  > > Yes, these other unices' solution seems far less general...
 > >  > 
 > >  > What do you mean?
 > > 
 > > The solution of putting everything into /usr/etc is IMHO less general
 > > than having a search path, be it in apps or in FS-driver.
 > I don't hink there is a problem with it, I heard no complaints.  And
 > about your proposal: I think that implementing this thing in kernel is
 > a Bad Thing.  I like the solution of one function
 > FILE *confopen(const char *path);
 > distributed from Debian site, for all maintainers to put it into their
 > programs.  The driver solution is interesting, but I think not
 > practical (after all, it doesn't belong to kernel).

confopen() surely doesn't, but what we could name my "file inheritance
scheme for directory" surely belongs to a FS' driver !

Yann Dirson <dirson@univ-mlv.fr>

TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .

Reply to: