public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Tupshin Harper <tupshin@tupshin.com>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: is KERNEL developement finished, yet ??? (ACLs)
Date: Thu, 05 Dec 2002 12:09:25 -0800	[thread overview]
Message-ID: <3DEFB275.9000807@tupshin.com> (raw)
In-Reply-To: <aso4kq$2ka$1@penguin.transmeta.com>

Linus Torvalds wrote:

> Only stupid people think they should throw away old proven concepts. 
> What happens quite often in academia in particular is that you find a
> problem you want to fix, and you re-design the whole system around your
> fix. 
Agreed...
> 
> The UNIX/Linux approach is a very pragmatic thing - leave the things
> that work well alone.  There's no point in re-inventing the whole system
> just because of some small perceived flaws. 
> 
Agreed...
> 
>>This is not a design flaw per say, but let's face it: Unix would be a lot
>>more secure (and more flexible in it's security) with ACL's.
>>
>>Microsoft Windows has had ACL's since 1991 (Windows NT 3.5?); that was 11
>>years ago.
> 
> 
> Yeah, and look how much more secure it is than UNIX.
> 
> 		Linus
An unfortunately inflamatory argument that avoids the real issue.  I'm 
not going to argue the security of NT (heaven forbid), but you do 
completely ignore the benefits of ACLs, including things that 
capabilities don't provide.

The fundamental problem is that while there is a many-to-many 
relationship between users and groups, there is only a one-to-many 
relationship between files and groups. This inequity breeds kludgy 
solutions to problems that would be easy with the many-to-many 
group/file relationships that ACLs provide

A simple example would be four non-root users of a system where user A 
would like to provide read and write access to a file with users B and C 
but not D and access to another file with C and D, but not B. Without 
ACLs this is jut not possible without root setting up one group that 
encompasses B and C, and another for C and D. Obviously not a scalable 
or convenient solution.

This trivial example get's magnified when trying to delegate 
administration tasks on a large system. In these cases, groups could 
feasibly be set up to encompass every permutation, but can quickly get 
unwieldy.

I'm not at all opposed to capabilities, but I don't believe they come 
close to obviating ACLs. It also doesn't seem ACLs and capabilities are 
in any kind of conflict. Why could we not have both?

-Tupshin


  parent reply	other threads:[~2002-12-05 19:53 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-12-05  2:00 is KERNEL developement finished, yet ??? Ed Vance
2002-12-05 12:24 ` Shane Helms
2002-12-05 12:54   ` Joseph D. Wagner
2002-12-05 13:15     ` Andreas Schwab
2002-12-05 18:07     ` Linus Torvalds
2002-12-05 19:52       ` Shane Helms
2002-12-05 20:03         ` Linus Torvalds
2002-12-05 20:09       ` Tupshin Harper [this message]
2002-12-06 10:38         ` is KERNEL developement finished, yet ??? (ACLs) Jakob Oestergaard
2002-12-15  5:29         ` Tracy R Reed
2002-12-07 20:34       ` is KERNEL developement finished, yet ??? Kai Henningsen
2002-12-05 18:09     ` Alan Cox
2002-12-05 17:47       ` yodaiken
2002-12-05 19:08       ` John Bradford
2002-12-06  6:15       ` Joseph D. Wagner
2002-12-06  6:30         ` John Alvord
2002-12-06  9:48         ` Alvaro Lopes
2002-12-07 20:43           ` Kai Henningsen
2002-12-07 20:39       ` Kai Henningsen
2002-12-09 14:08         ` Jesse Pollard
2002-12-10  0:26           ` H. Peter Anvin
2002-12-05 14:33   ` Mikael Pettersson

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=3DEFB275.9000807@tupshin.com \
    --to=tupshin@tupshin.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@transmeta.com \
    /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