mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Trever L. Adams" <tadams-lists@myrealbox.com>
To: Jesse Pollard <pollard@admin.navo.hpc.mil>
Cc: Rusty Russell <rusty@rustcorp.com.au>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: The ACL debate (was: Re: What's left over.)
Date: 31 Oct 2002 15:28:40 -0500	[thread overview]
Message-ID: <1036096120.1510.5.camel@aurora.localdomain> (raw)
In-Reply-To: <200210311047.07774.pollard@admin.navo.hpc.mil>

On Thu, 2002-10-31 at 11:47, Jesse Pollard wrote:
> On Thursday 31 October 2002 04:59 am, Trever L. Adams wrote:
> > 5) Only root can change group ownership of a file
> 
> not quite - the owner of the file may change the group ownership to
> any other group that the owner is a member.
> 
> It does require root to change a file group to a group the owner is
> not a member of.
> 

I guess my experience with playing with groups is lacking.  I had tried
this, but I guess I always tried with groups I wasn't a member of.  I
still believe this is bad form, but probably has historical and valid
reasons for it.

> >Why ACLs are bad:
> 
> ACLs alone are not enough. ACLs alone allow a user to grant
> access to any other user/group. For situations that require a fence
> between users (ie. accounting/parts inventory) only a mandatory
> access control (MAC) would be able to prevent such improper
> data sharing. It is also a problem in government use. At least on
> large, shared resource systems.
> 

I see your point here too.  I usually see things from a perspective of
companies not needing this.   I mean "a house divided..." and all that. 
But I guess companies would rather force unity than let the one person
screw them over.  Point to you on the debate for sure.  I know there
have been MAC implementations for Linux... is one in 2.5?

> Mitigating factors:
> 
> Adding MAC restores facility control, and still allows the user
> some flexibility to create ad-hoc groups within an administratively
> defined population group.
> 

Sounds very good.  I would think for those who know they are united,
that MAC or ACL should not auto-define the other.  Having both, on
option, is nice though.

> The normal UNIX solution is to have multiple systems, each dedicated
> to a relatively small population where any user is authorized to access
> data on that system (this is where limited groups come in), but owners
> of the data may provide a more restricted access.
> 

Hardware is getting more powerful, why segment it through such physical
means?


> A large resource usually has to be shared (wind tunnel simulations,
> finite element analysis of different structures, large inventory
> management...). And sharing doesn't necessarily involve sharing
> data.

Understood.  You had many good points.  I still don't see it as a user
space problem though.  These are all things that go in the kernel...
Yes, policy doesn't belong in the kernel, but the ability to create
policy and enforce it does (where user-space may not be the right place,
such as here).

I guess I agree with you, but I still think ACLs are necessary and
wanted, even if there needs to be additional functionality for those who
are totally paranoid (some corps, governments, etc.)

Trever Adams

P.S.  I removed Linus from direct in the email because he has said he is
going to add it already.


  reply	other threads:[~2002-10-31 20:22 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-31 10:59 Trever L. Adams
2002-10-31 16:47 ` Jesse Pollard
2002-10-31 20:28   ` Trever L. Adams [this message]
2002-10-31 21:53     ` Jesse Pollard

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=1036096120.1510.5.camel@aurora.localdomain \
    --to=tadams-lists@myrealbox.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pollard@admin.navo.hpc.mil \
    --cc=rusty@rustcorp.com.au \
    /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

all inboxes | Powered by JetHome®