From: Bill Crawford <billc@netcomuk.co.uk>
To: vda <vda@port.imtp.ilyichevsk.odessa.ua>
Cc: bill@eb0ne.net, linux-kernel@vger.kernel.org
Subject: Re: Linux-kernel-daily-digest digest, Vol 1 #171 - 281 msgs
Date: Wed, 21 Nov 2001 18:13:01 +0000 [thread overview]
Message-ID: <3BFBEEAD.67DF8932@netcomuk.co.uk> (raw)
In-Reply-To: <200111201202.fAKC2Md29689@lists.us.dell.com> <01112112032600.01961@nemo> <3BFBC5C5.82366455@netcomuk.co.uk> <01112117394902.02798@nemo>
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
};
prev parent reply other threads:[~2001-11-21 18:13 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200111201202.fAKC2Md29689@lists.us.dell.com>
[not found] ` <3BFA8AE2.2B5FA0@netcomuk.co.uk>
[not found] ` <01112112032600.01961@nemo>
2001-11-21 15:18 ` Linux-kernel-daily-digest digest, Vol 1 #171 - 281 msgs Bill Crawford
2001-11-21 17:39 ` vda
2001-11-21 18:13 ` Bill Crawford [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3BFBEEAD.67DF8932@netcomuk.co.uk \
--to=billc@netcomuk.co.uk \
--cc=bill@eb0ne.net \
--cc=linux-kernel@vger.kernel.org \
--cc=vda@port.imtp.ilyichevsk.odessa.ua \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.