Re: Linux-kernel-daily-digest digest, Vol 1 #171 - 281 msgs

Re: Linux-kernel-daily-digest digest, Vol 1 #171 - 281 msgs

[Bill Crawford]

vda wrote:

> >  Perhaps we should not distinguish between read and execute on programs
> > either?  After all, they're not much different, are they?

 This was intended to be sarcastic :o)

> Yes, we can. In fact, NT lives with it with no problem. It is very common
> in NT to have rx on all readable files regardless of their 'executability'.
> If someone have 'r' perms, he can make a copy of a file, flag it with x and
> execute.

 In theory one can do just that on Un*x systems too.  That's why setid
bits can't be set by just anybody.

 What if the program is setuid and executable by a group but not other?
We do this with "su" on servers.

 Now, ACLs I want to see widely supported on Linux, and *used* properly
too.  They've been little used in most environments I've seen even on
systems that do support them, which is a shame as they are a necessary
and useful idea.  Yes, the Un*x permissions system does have some
limitations, but let's not break *all* the existing software and OSs
that use them, since what you're suggesting will not improve things.

> versions of it). It's too late. I've made patch for chmod which adds new +R
> flag to that effect.

 Why is that needed anyway?  By default directories get execute bit set
when they're created, at least in my environment; if you're extending
permissions you can use "go=u" or "o=g" to broaden the permissions, as
I would expect the existing perms to be correct on files vs directories
in most cases.

> --
> vda

-- 
/* Bill Crawford, Unix Systems Developer, Ebone (formerly GTS Netcom) */
#include <stddiscl>
const char *addresses[] = {
    "bill@syseng.netcom.net.uk", "Bill.Crawford@ebone.com",     // work
    "billc@netcomuk.co.uk", "bill@eb0ne.net"                    // home
};

Re: Linux-kernel-daily-digest digest, Vol 1 #171 - 281 msgs

[vda]

On Wednesday 21 November 2001 15:18, Bill Crawford wrote:
>  Now, ACLs I want to see widely supported on Linux, and *used* properly
> too.  They've been little used in most environments I've seen even on
> systems that do support them, which is a shame as they are a necessary
> and useful idea.  Yes, the Un*x permissions system does have some
> limitations, but let's not break *all* the existing software and OSs
> that use them, since what you're suggesting will not improve things.

Hmm. I thought proper group management can let you live with std UNIX
file permissions model... NT ACLs are horrendously complex.
"Make it as simple as possible, but not simpler"

> > versions of it). It's too late. I've made patch for chmod which adds new
> > +R flag to that effect.

>  Why is that needed anyway?  By default directories get execute bit set
> when they're created, at least in my environment; if you're extending
> permissions you can use "go=u" or "o=g" to broaden the permissions, as
> I would expect the existing perms to be correct on files vs directories
> in most cases.

It is legitimate to do that. Do I really have to explain?

I have a script which is designed to sweep entire tree starting from /
and do some sanity checks. For example, it Opens Source:

chmod -R -c a+R /usr/src

8-)

--
vda

Re: Linux-kernel-daily-digest digest, Vol 1 #171 - 281 msgs

[Bill Crawford]

vda wrote:

> Hmm. I thought proper group management can let you live with std UNIX
> file permissions model... NT ACLs are horrendously complex.
> "Make it as simple as possible, but not simpler"

 You can, but there are situations where you end up with a combinatorial
explosion of groups to accommodate a matrix of possible permissions on
things.  And there is another significantly limiting factor which is the
restriction on the number of groups a process can belong to (currently
32 I believe).

 I think ACLs are a good solution to the problem, and indeed are what
*should* have been done originally ... however I suspect that would have
added a significant overhead to the original UNIX, and one of the great
benefits at the time was that UNIX was designed to run on pretty low-end
hardware.  VMS was a heavyweight beast on VAXen, did it ever run on PDP
machines?  There was a complex system :o)

 I'm thinking of Solaris' ACLs rather than NT, I don't know much about
the latter so I can't really comment on them.

> It is legitimate to do that. Do I really have to explain?

 No, I know what you're trying to do.  I have done it myself many times.
Why some sources come packed so they're only readable by root is beyond
me :o)

> I have a script which is designed to sweep entire tree starting from /
> and do some sanity checks. For example, it Opens Source:
> 
> chmod -R -c a+R /usr/src
> 
> 8-)

 OK, point conceded, although I can live with two passes for that sort
of thing.  Yours is a neat solution in fact.

> --
> vda

-- 
/* Bill Crawford, Unix Systems Developer, Ebone (formerly GTS Netcom) */
#include <stddiscl>
const char *addresses[] = {
    "bill@syseng.netcom.net.uk", "Bill.Crawford@ebone.com",     // work
    "billc@netcomuk.co.uk", "bill@eb0ne.net"                    // home
};