access control list for files

access control list for files

[Mohammed Khalid Ansari]

HI

I want your comments on the following...

Is this not a good idea that each and every file must have a access
control list associated with it like in widows so that I define the users
who can read, write or execute a particular file. I can't do this in
UNIX/Linux as we have to maintain only three groups (owner, group and
others). I can't create groups on my own and if I happened to be the
administrator then also its no feasible to create ACL as I will have to
create too many groups.

How best we can go in UNIX/Linux.

with regards....

-- 

**************************************************************************

Mohammed Khalid Ansari                    Tel (res) : 0091-022-3051360
Assistant Manager II                          (off) : 0091-022-2024641
National Centre for Software Technology   Fax       : 0091-022-2049573 
8th flr,Air India Build. Nariman Point,   E-Mail    : khalid@ncst.ernet.in 	
Mumbai 400021.

Homepage : http://soochak.ncst.ernet.in/~khalid			  	  

**************************************************************************

Re: access control list for files

[terry white]

on "9-16-2002" "Mohammed Khalid Ansari" writ:

: I can't do this in UNIX/Linux as we have to maintain only three groups
: (owner, group and others).

... these are NOT groups , they are SETS of permisions.

: I can't create groups on my own and if I happened to be the
: administrator then also its no feasible to create ACL as I will have to
: create too many groups.

    seems to me, an ACL just a list of users, or GROUP, for short.  just
translate the win philosophy to linux.  however, if you don't have
'root', it doesn't really matter.  if however, you do, 'apropos group' is
a suggested starting place ...


-- 
... i'm a man, but i can change,
    if i have to , i guess ...

Re: access control list for files

[Milan P. Stanic]

On Mon, Sep 16, 2002 at 11:30:01AM +0530, Mohammed Khalid Ansari wrote:
> I want your comments on the following...
> 
> Is this not a good idea that each and every file must have a access
> control list associated with it like in widows so that I define the users
> who can read, write or execute a particular file. I can't do this in
> UNIX/Linux as we have to maintain only three groups (owner, group and
> others). I can't create groups on my own and if I happened to be the
> administrator then also its no feasible to create ACL as I will have to
> create too many groups.
> 
> How best we can go in UNIX/Linux.

There are more solutions for ACL on Linux and it depends on the
file-system type, because it is implemented trough file-system driver.

IMHO for ext2/ext3 ACL patch at http://acl.bestbits.at/ are most
promising. And samba can be compiled to support it.
 
Milan

Re: access control list for files

[Glynn Clements]

terry white wrote:

> : I can't create groups on my own and if I happened to be the
> : administrator then also its no feasible to create ACL as I will have to
> : create too many groups.
> 
>     seems to me, an ACL just a list of users, or GROUP, for short.  just
> translate the win philosophy to linux.  however, if you don't have
> 'root', it doesn't really matter.  if however, you do, 'apropos group' is
> a suggested starting place ...

AFAICT, the issues to which Mohammed is referring are:

1. With ACLs, a user can grant permissions to an arbitrary set of
users whereas, with Unix groups, you have to select a group as defined
by /etc/group, and most users don't have write permission on
/etc/group.

2. Even if a user could define groups, group membership is typically
determined at "login" time. Adding a user to a new group won't have
any impact upon any existing processes running under that account. 
With ACLs, the membership test is performed when the file is opened.

3. You can't directly grant read permission to one set of users and
write permission to a different set of users.

Unfortunately, implementing ACLs is the (relatively) easy part. The
awkward part is that a lot of existing software has been designed to
use the standard Unix API, and a fair amount of it relies upon:

a) chown(), chgrp(), chmod() etc working accordingly, and

b) being able to deduce the accessibility of a file from the results
of stat() etc.

If an enhancement meant that a file could be read or written when,
using the existing semantics would mean that it could not, that would
present a security risk.

Of the above, a) is the easy part; you just reset the ACL whenever the
permissions are changed using the conventional Unix mechanisms.
Dealing with b) is somewhat more difficult.

You could avoid under-reporting the accessibility by indicating that
the file was world-readable or world-writable whenever it had a read
ACL or a write ACL respectively. This should eliminate any security
risks, although it might introduce other problems.

-- 
Glynn Clements <glynn.clements@virgin.net>

Re: access control list for files

[Mohammed Khalid Ansari]

I want to know teh UNIX/Linux users opinion on whether it is better to
introduce ACLs in the file systems?


On Mon, 16 Sep 2002, Glynn Clements wrote:

> 
> terry white wrote:
> 
> > : I can't create groups on my own and if I happened to be the
> > : administrator then also its no feasible to create ACL as I will have to
> > : create too many groups.
> > 
> >     seems to me, an ACL just a list of users, or GROUP, for short.  just
> > translate the win philosophy to linux.  however, if you don't have
> > 'root', it doesn't really matter.  if however, you do, 'apropos group' is
> > a suggested starting place ...
> 
> AFAICT, the issues to which Mohammed is referring are:
> 
> 1. With ACLs, a user can grant permissions to an arbitrary set of
> users whereas, with Unix groups, you have to select a group as defined
> by /etc/group, and most users don't have write permission on
> /etc/group.
> 
> 2. Even if a user could define groups, group membership is typically
> determined at "login" time. Adding a user to a new group won't have
> any impact upon any existing processes running under that account. 
> With ACLs, the membership test is performed when the file is opened.
> 
> 3. You can't directly grant read permission to one set of users and
> write permission to a different set of users.
> 
> Unfortunately, implementing ACLs is the (relatively) easy part. The
> awkward part is that a lot of existing software has been designed to
> use the standard Unix API, and a fair amount of it relies upon:
> 
> a) chown(), chgrp(), chmod() etc working accordingly, and
> 
> b) being able to deduce the accessibility of a file from the results
> of stat() etc.
> 
> If an enhancement meant that a file could be read or written when,
> using the existing semantics would mean that it could not, that would
> present a security risk.
> 
> Of the above, a) is the easy part; you just reset the ACL whenever the
> permissions are changed using the conventional Unix mechanisms.
> Dealing with b) is somewhat more difficult.
> 
> You could avoid under-reporting the accessibility by indicating that
> the file was world-readable or world-writable whenever it had a read
> ACL or a write ACL respectively. This should eliminate any security
> risks, although it might introduce other problems.
> 
>