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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox