Re: [OpenAFS] Re: Ideas for finer grain set acl controls

[Russ Allbery]

Andrew Deason  writes:
> Russ Allbery  wrote:

>> It's not as important as being able to block system:anyuser, but yes,
>> I'd ideally like to be able to block arbitrary PTS groups from being
>> added to ACLs with "all" or "write" access.

> Thanks for being the first to speak up, but I want to make clear that
> this sub-thread was specifically about system:authuser restrictions,
> since it's kind of a special case. Blocking "arbitrary PTS groups" from
> getting certain rights in ACLs has issues.

I don't see much utility in blocking system:authuser specifically.

system:anyuser is the low-hanging fruit.  Outside of system:anyuser, I
think the next meaningful level of feature is blocking arbitrary
admin-specified groups or users from being given write or admin access.
I don't think system:authuser is sufficiently interesting to be worth a
lot of attention outside of supporting arbitrary restrictions.

> The thing is, for the non-special groups (i.e. most groups), blocking a
> specific group people.foo in an ACL doesn't do much. Since you can just
> 'pts add people.foo adeason:foo', and then put adeason:foo in the ACL.
> Unless we also change the permissions of supergroup creation or
> something, there's not really a way around that.

That's okay.  I don't need something that can't be worked around, just
something that catches users who don't knowo what they're doing.

-- 
Russ Allbery (r...@stanford.edu) 
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] Re: Ideas for finer grain set acl controls

[Christopher D. Clausen]

Alf Wachsmann  wrote:

On Thu, 12 Nov 2009, Russ Allbery wrote:

Andrew Deason  writes:

In other words: *** PLEASE SPEAK UP *** if you want to be able to
prevent normal users from doing something like "fs setacl ${HOME}
system:authuser rlidwka" even when they have the 'a' bit on ${HOME}.



Even if it's just "+1, yes, I want that", please say something.


It's not as important as being able to block system:anyuser, but
yes, I'd ideally like to be able to block arbitrary PTS groups from
being added to ACLs with "all" or "write" access.


What he said. I would like that feature.


Me too!

Also, I would like separate "change acl" and "add mount point" 
permissions.  I often end up granting "a" just so that users can add 
mount points as I see mount points as one of the key benefits of AFS. 
The end user can define their view of the file space and not have to 
resort to hard-coded things like symlinks or hardlinks.


Some users just cannot be trusted to manage their own ACLs though.

[OpenAFS] Re: Ideas for finer grain set acl controls

[Andrew Deason]

On Thu, 12 Nov 2009 12:23:20 -0800
Russ Allbery  wrote:

> Andrew Deason  writes:
> 
> > In other words: *** PLEASE SPEAK UP *** if you want to be able to
> > prevent normal users from doing something like "fs setacl ${HOME}
> > system:authuser rlidwka" even when they have the 'a' bit on ${HOME}.
> 
> > Even if it's just "+1, yes, I want that", please say something.
> 
> It's not as important as being able to block system:anyuser, but yes,
> I'd ideally like to be able to block arbitrary PTS groups from being
> added to ACLs with "all" or "write" access.

Thanks for being the first to speak up, but I want to make clear that
this sub-thread was specifically about system:authuser restrictions,
since it's kind of a special case. Blocking "arbitrary PTS groups" from
getting certain rights in ACLs has issues. Such issues been discussed
elsewhere, but really quickly for everyone:

The thing is, for the non-special groups (i.e. most groups), blocking a
specific group people.foo in an ACL doesn't do much. Since you can just
'pts add people.foo adeason:foo', and then put adeason:foo in the ACL.
Unless we also change the permissions of supergroup creation or
something, there's not really a way around that.

So we have some different mechanisms for 'normal' groups, but those are
outlined in that big "3 methods" email.

-- 
Andrew Deason
adea...@sinenomine.net

___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] Re: Ideas for finer grain set acl controls

[Ben Poliakoff]

* Andrew Deason  [20091112 12:13]:
> On Thu, 12 Nov 2009 14:51:11 -0500
> Michael Meffie  wrote:
> 
> > > It seems to me that restricting system:authuser would be less common
> > > than anyuser/anonymous, but it still could be useful; and we have
> > > other methods that cover the use case.
> > 
> > I'm failing to see a use case here. Anyone on this list have a
> > concrete example?
> 
> In other words: *** PLEASE SPEAK UP *** if you want to be able to
> prevent normal users from doing something like "fs setacl ${HOME}
> system:authuser rlidwka" even when they have the 'a' bit on ${HOME}.
> 
> Even if it's just "+1, yes, I want that", please say something.
> 

We'd certainly appreciate that capability at our site.

+1

Ben

-- 

PGP key updated: http://www.reed.edu/~benp/key-transition-2009-05-11.txt
PGP (318B6A97):  3F23 EBC8 B73E 92B7 0A67  705A 8219 DCF0 318B 6A97


signature.asc
Description: Digital signature

Re: [OpenAFS] Re: Ideas for finer grain set acl controls

[Alf Wachsmann]

On Thu, 12 Nov 2009, Russ Allbery wrote:

Andrew Deason  writes:

In other words: *** PLEASE SPEAK UP *** if you want to be able to
prevent normal users from doing something like "fs setacl ${HOME}
system:authuser rlidwka" even when they have the 'a' bit on ${HOME}.



Even if it's just "+1, yes, I want that", please say something.


It's not as important as being able to block system:anyuser, but yes, I'd
ideally like to be able to block arbitrary PTS groups from being added to
ACLs with "all" or "write" access.


What he said. I would like that feature.

-- Alf.

---
  Alf Wachsmann   | e-mail: a...@slac.stanford.edu
  SLAC - Scientific Computing | Phone:  +1-650-926-4802
  2575 Sand Hill Road, M/S 97 | FAX:+1-650-926-3329
  Menlo Park, CA 94025, USA   | Office: Bldg. 50/323
---
http://www.slac.stanford.edu/~alfw (PGP)
---
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] Re: Ideas for finer grain set acl controls

[Russ Allbery]

Andrew Deason  writes:

> In other words: *** PLEASE SPEAK UP *** if you want to be able to
> prevent normal users from doing something like "fs setacl ${HOME}
> system:authuser rlidwka" even when they have the 'a' bit on ${HOME}.

> Even if it's just "+1, yes, I want that", please say something.

It's not as important as being able to block system:anyuser, but yes, I'd
ideally like to be able to block arbitrary PTS groups from being added to
ACLs with "all" or "write" access.

-- 
Russ Allbery (r...@stanford.edu) 
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

[OpenAFS] Re: Ideas for finer grain set acl controls

[Andrew Deason]

On Thu, 12 Nov 2009 14:51:11 -0500
Michael Meffie  wrote:

> > It seems to me that restricting system:authuser would be less common
> > than anyuser/anonymous, but it still could be useful; and we have
> > other methods that cover the use case.
> 
> I'm failing to see a use case here. Anyone on this list have a
> concrete example?

In other words: *** PLEASE SPEAK UP *** if you want to be able to
prevent normal users from doing something like "fs setacl ${HOME}
system:authuser rlidwka" even when they have the 'a' bit on ${HOME}.

Even if it's just "+1, yes, I want that", please say something.

-- 
Andrew Deason
adea...@sinenomine.net
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] Re: Ideas for finer grain set acl controls

[Michael Meffie]

Andrew Deason wrote:

On Thu, 12 Nov 2009 11:47:12 -0500
Michael Meffie  wrote:


Andrew Deason wrote:

While this could be helpful, this don't solve the problem for the
various system:authuser groups or host groups.

Can you expand on that a bit? What is the problem with the host ip
groups? As far as I can see the host rights would still be honored
even if we had a negative rights for the anonymous user.


Yes, but what if you want to prevent people assigning rlidwka rights to
a very big host group, e.g. 18.0.0.0? I suppose maybe calling it a
"problem" is a bit much; I just meant a missing feature.


Ok, I see your point there, you mean to control of the
creating of host ip groups and the acls for those.  Yes,
but that seems to be a different issue I think.



What are the issues with system:authuser groups that I'm not
seeing?


In the format I was using... "How do I prevent people from giving
system:authuser write/admin access?" You don't want to give a
volume-wide negative ACL for system:authuser idwa, as that prevents any
authenticated user from write/admin access. We don't have an entry
analogous to the 'anonymous' user for this case, because... well, the
acessing users aren't anonymous.

It seems to me that restricting system:authuser would be less common
than anyuser/anonymous, but it still could be useful; and we have other
methods that cover the use case.


I'm failing to see a use case here. Anyone on this list have a
concrete example?

Mike --
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

[OpenAFS] Re: Ideas for finer grain set acl controls

[Andrew Deason]

On Thu, 12 Nov 2009 11:47:12 -0500
Michael Meffie  wrote:

> Andrew Deason wrote:
> > While this could be helpful, this don't solve the problem for the
> > various system:authuser groups or host groups.
> 
> Can you expand on that a bit? What is the problem with the host ip
> groups? As far as I can see the host rights would still be honored
> even if we had a negative rights for the anonymous user.

Yes, but what if you want to prevent people assigning rlidwka rights to
a very big host group, e.g. 18.0.0.0? I suppose maybe calling it a
"problem" is a bit much; I just meant a missing feature.

> What are the issues with system:authuser groups that I'm not
> seeing?

In the format I was using... "How do I prevent people from giving
system:authuser write/admin access?" You don't want to give a
volume-wide negative ACL for system:authuser idwa, as that prevents any
authenticated user from write/admin access. We don't have an entry
analogous to the 'anonymous' user for this case, because... well, the
acessing users aren't anonymous.

It seems to me that restricting system:authuser would be less common
than anyuser/anonymous, but it still could be useful; and we have other
methods that cover the use case.

-- 
Andrew Deason
adea...@sinenomine.net
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] Re: Ideas for finer grain set acl controls

[Michael Meffie]

Andrew Deason wrote:

On Wed, 11 Nov 2009 14:42:53 -0500
Derrick Brashear  wrote:


You can't. If we allow you to specify the 'anonymous' user, you
could assign negative idwka rights to 'anonymous' on the
volume-level ACL to prevent system:anyuser write access. But there
is no way to prevent access for system:authuser.

Note: giving a negative ACL on, say, system:anyuser would prevent
_any_ user from getting rights; that's not what we'd want.

Since system:anyuser represents all users, it seems to me we could
introduce a way to indicate anonymous users. Perhaps with a new
system group, system:anonusers which represents users that are
not authenticed?


While this could be helpful, this don't solve the problem for the
various system:authuser groups or host groups.


Can you expand on that a bit? What is the problem with the host ip
groups? As far as I can see the host rights would still be honored
even if we had a negative rights for the anonymous user.

What are the issues with system:authuser groups that I'm not
seeing?




At that point we would specify a volume level negative right,

Negative rights:
 system:anonusers idwka

Why do you need a group, as opposed to simply mapping 32766 to a name?


We already have a name, too: anonymous. Why can't we specify that in
normal ACLs now, anyway? Does it just have to do with how the ptserver
returns errors?



I suspect there are error handling implications, because 32766 cannot be a
pts id.

___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

[OpenAFS] Re: Ideas for finer grain set acl controls

[Andrew Deason]

On Wed, 11 Nov 2009 14:42:53 -0500
Derrick Brashear  wrote:

> >> You can't. If we allow you to specify the 'anonymous' user, you
> >> could assign negative idwka rights to 'anonymous' on the
> >> volume-level ACL to prevent system:anyuser write access. But there
> >> is no way to prevent access for system:authuser.
> >>
> >> Note: giving a negative ACL on, say, system:anyuser would prevent
> >> _any_ user from getting rights; that's not what we'd want.
> >
> > Since system:anyuser represents all users, it seems to me we could
> > introduce a way to indicate anonymous users. Perhaps with a new
> > system group, system:anonusers which represents users that are
> > not authenticed?

While this could be helpful, this don't solve the problem for the
various system:authuser groups or host groups.

> > At that point we would specify a volume level negative right,
> >
> > Negative rights:
> >  system:anonusers idwka
> 
> Why do you need a group, as opposed to simply mapping 32766 to a name?

We already have a name, too: anonymous. Why can't we specify that in
normal ACLs now, anyway? Does it just have to do with how the ptserver
returns errors?

-- 
Andrew Deason
adea...@sinenomine.net

___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] Re: Ideas for finer grain set acl controls

[Derrick Brashear]

oint we would specify a volume level negative right,
>>>
>>> Negative rights:
>>>  system:anonusers idwka
>>
>> Why do you need a group, as opposed to simply mapping 32766 to a name?
>
> Yes, I suppose just a way to represent ANONYMOUSID (32766) would
> work, but the system: prefix seems intuitive to me and more
> consistent with system:anyuser and system:authuser.

Well, those are groups of identities: "all authenticated users" or
"all authenticated users plus anonymous", anonymous is but one
identity!


-- 
Derrick
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] Re: Ideas for finer grain set acl controls

[Michael Meffie]

Derrick Brashear wrote:

You can't. If we allow you to specify the 'anonymous' user, you could
assign negative idwka rights to 'anonymous' on the volume-level ACL to
prevent system:anyuser write access. But there is no way to prevent
access for system:authuser.

Note: giving a negative ACL on, say, system:anyuser would prevent _any_
user from getting rights; that's not what we'd want.

Since system:anyuser represents all users, it seems to me we could
introduce a way to indicate anonymous users. Perhaps with a new
system group, system:anonusers which represents users that are
not authenticed?

At that point we would specify a volume level negative right,

Negative rights:
 system:anonusers idwka


Why do you need a group, as opposed to simply mapping 32766 to a name?


Yes, I suppose just a way to represent ANONYMOUSID (32766) would
work, but the system: prefix seems intuitive to me and more
consistent with system:anyuser and system:authuser.

Mike --
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] Re: Ideas for finer grain set acl controls

[Derrick Brashear]

>> You can't. If we allow you to specify the 'anonymous' user, you could
>> assign negative idwka rights to 'anonymous' on the volume-level ACL to
>> prevent system:anyuser write access. But there is no way to prevent
>> access for system:authuser.
>>
>> Note: giving a negative ACL on, say, system:anyuser would prevent _any_
>> user from getting rights; that's not what we'd want.
>
> Since system:anyuser represents all users, it seems to me we could
> introduce a way to indicate anonymous users. Perhaps with a new
> system group, system:anonusers which represents users that are
> not authenticed?
>
> At that point we would specify a volume level negative right,
>
> Negative rights:
>  system:anonusers idwka

Why do you need a group, as opposed to simply mapping 32766 to a name?

Derrick
___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Re: [OpenAFS] Re: Ideas for finer grain set acl controls

[Michael Meffie]

Andrew Deason wrote:

Recent discussions have shown that there are a few possible ways we
could go about restricting ACL-setting access. With this email I hope to
detail all of the ones that have come up so far, and demonstrate the
pros and cons of each.


Andrew,

Thank you for expanding on the ideas being considered.

There seems to be consensus a volume level control is what is
desired, regardless of the options currently under consideration.

My opinion is we need to find an option that would be must
intuitive to end-users, and I'm not sure we know enough yet
to say which approach would be the least confusing and
surprising for end-users. I hope some others will chime in
to express some opinions.



Since the rest of this is quite long, here's a quick summary of the
conclusions. We have three methods: 'method 1' is the "volume ACL
policies" idea, 'method 2' is the "volume-level ACL overlays" idea, and
'method 3' is the "volume ACL masks" idea. To cover all uses cases, we'd
either do method 1, or a combination of 2 and 3. Or we could just
implement all of them; I don't see anything stopping us from
implementing everything desribed here.

The bottom line is that I find method 1 to be the most flexible and the
least confusing to end-users, but it is the most confusing to
administrators, and it is the slowest (when changing the volume-level
permissions). Using methods 2+3 has the opposite pros/cons.

Here are the details. Each method has an explanation for what it
generally is and how it works, followed by its use in a few simple
use-case scenarios, followed by the pros/cons.

Method 1, "volume ACL policies":

With this method, we maintain policies of who is allowed to set what ACLs
in a volume. For example, to allow nobody but system:powerusers to grant
idwka rights to system:anyuser, we'd have a policy for system:anyuser
that would look like this:

system:powerusers rlidwka
system:anyuserrl

After that policy is set, any time a user not in system:powerusers tries
to grant system:anyuser more than rl rights, they will get an EACCES
error. This does not change the existing ACLs in the volume; an
administrator will need to run an auditing tool to make sure that
existing ACLs comply with the volume policy.

"How do I prevent system:anyuser/system:authuser write access?"
--

You would call something like this

 vos setpolicy -add-positive   \
   -user system:anyuser\
   -set-rights rl  \
   -for-user system:anyuser\
   -in-volume user.adeason

to prevent people fromt giving system:anyuser write access. To ensure
that existing ACLs don't permit write access, you would need to run
something like

 vos auditpolicy -vol user.adeason

"How do I prevent group.foo write access?"
--

To prevent an arbitrary normal group from getting write access, things
are slightly different. You would need to prevent users from taking away
negative idwka rights, and then assign negative idwka rights to all
directories in the volume. So, something like

 vos setpolicy -remove-negative \
   -user system:anyuser \
   -set-rights rl   \
   -for-user group.foo  \
   -in-volume user.adeason

Would allow users to only remove 'rl' rights from group.foo in negative
ACLs. Then you would need to set negative idwka ACLs on all directories
in the volume.

"How do I guarantee group.bar read access?"
--

Prevent normal users from taking away read access from group.bar, and
from granting negative read access for group.bar:

 vos setpolicy -remove-positive \
   -user system:anyuser \
   -set-rights idwka\
   -for-user group.bar  \
   -in-volume user.adeason
 
 vos setpolicy -add-negative\

   -user system:anyuser \
   -set-rights idwka\
   -for-user group.bar  \
   -in-volume user.adeason

Then, grant read access for group.bar in all directories in the volume.

Method 1 pros:

 - More flexible for a variety of situations. In particular, this allows
   administrators (or an arbitrary administrator-defined set of users)
   to override the volume policies, and set e.g.  system:anyuser write
   on a particular directory if they wish.

 - No performance overhead at access-check time. All of the additional
   access checks are done during SetACL.
 
 - Minimal end-user confusion. ACLs accurately represent exactly what

   rights different users have. Trying to set an ACL that violates the
   policy will result in EACCES, so they know the SetACL operation
   didn't work. It may be confusing as to why it did not, but at least
   it is clear that the ACL was not changed.
 
Method 1 cons:


 - Volumes need to be 'audited' (or all of the ACLs just need to be set)
   to make sure they comply with the ACL policy, which can be slow, and
   is just another step that needs to be done.
 
 - Higher end-administrator confusion (perhaps). Setting the policies

   can get confusing.

Method 2, "volume-level ACL overlays":

With this method, we maintain a 

[OpenAFS] Re: Ideas for finer grain set acl controls

[Andrew Deason]

Recent discussions have shown that there are a few possible ways we
could go about restricting ACL-setting access. With this email I hope to
detail all of the ones that have come up so far, and demonstrate the
pros and cons of each.

Since the rest of this is quite long, here's a quick summary of the
conclusions. We have three methods: 'method 1' is the "volume ACL
policies" idea, 'method 2' is the "volume-level ACL overlays" idea, and
'method 3' is the "volume ACL masks" idea. To cover all uses cases, we'd
either do method 1, or a combination of 2 and 3. Or we could just
implement all of them; I don't see anything stopping us from
implementing everything desribed here.

The bottom line is that I find method 1 to be the most flexible and the
least confusing to end-users, but it is the most confusing to
administrators, and it is the slowest (when changing the volume-level
permissions). Using methods 2+3 has the opposite pros/cons.

Here are the details. Each method has an explanation for what it
generally is and how it works, followed by its use in a few simple
use-case scenarios, followed by the pros/cons.

Method 1, "volume ACL policies":

With this method, we maintain policies of who is allowed to set what ACLs
in a volume. For example, to allow nobody but system:powerusers to grant
idwka rights to system:anyuser, we'd have a policy for system:anyuser
that would look like this:

system:powerusers rlidwka
system:anyuserrl

After that policy is set, any time a user not in system:powerusers tries
to grant system:anyuser more than rl rights, they will get an EACCES
error. This does not change the existing ACLs in the volume; an
administrator will need to run an auditing tool to make sure that
existing ACLs comply with the volume policy.

"How do I prevent system:anyuser/system:authuser write access?"
--

You would call something like this

 vos setpolicy -add-positive   \
   -user system:anyuser\
   -set-rights rl  \
   -for-user system:anyuser\
   -in-volume user.adeason

to prevent people fromt giving system:anyuser write access. To ensure
that existing ACLs don't permit write access, you would need to run
something like

 vos auditpolicy -vol user.adeason

"How do I prevent group.foo write access?"
--

To prevent an arbitrary normal group from getting write access, things
are slightly different. You would need to prevent users from taking away
negative idwka rights, and then assign negative idwka rights to all
directories in the volume. So, something like

 vos setpolicy -remove-negative \
   -user system:anyuser \
   -set-rights rl   \
   -for-user group.foo  \
   -in-volume user.adeason

Would allow users to only remove 'rl' rights from group.foo in negative
ACLs. Then you would need to set negative idwka ACLs on all directories
in the volume.

"How do I guarantee group.bar read access?"
--

Prevent normal users from taking away read access from group.bar, and
from granting negative read access for group.bar:

 vos setpolicy -remove-positive \
   -user system:anyuser \
   -set-rights idwka\
   -for-user group.bar  \
   -in-volume user.adeason
 
 vos setpolicy -add-negative\
   -user system:anyuser \
   -set-rights idwka\
   -for-user group.bar  \
   -in-volume user.adeason

Then, grant read access for group.bar in all directories in the volume.

Method 1 pros:

 - More flexible for a variety of situations. In particular, this allows
   administrators (or an arbitrary administrator-defined set of users)
   to override the volume policies, and set e.g.  system:anyuser write
   on a particular directory if they wish.

 - No performance overhead at access-check time. All of the additional
   access checks are done during SetACL.
 
 - Minimal end-user confusion. ACLs accurately represent exactly what
   rights different users have. Trying to set an ACL that violates the
   policy will result in EACCES, so they know the SetACL operation
   didn't work. It may be confusing as to why it did not, but at least
   it is clear that the ACL was not changed.
 
Method 1 cons:

 - Volumes need to be 'audited' (or all of the ACLs just need to be set)
   to make sure they comply with the ACL policy, which can be slow, and
   is just another step that needs to be done.
 
 - Higher end-administrator confusion (perhaps). Setting the policies
   can get confusing.

Method 2, "volume-level ACL overlays":

With this method, we maintain a single additional ACL in the volume
metadata, which is applied to access checks in the volume, after
performing the per-directory ACL check. It can be thought of as similar
to the fileserver -implicit flag, but more generalized.

For example, if we wanted a volume where system:backups was guaranteed
to have 'rl' rights, and system:evilusers was guaranteed to not have
_any_ rights, the volume-level ACL would look like:

positive:
 system:backups rl
negative:
 system:evilusers rlid

[OpenAFS] Re: Ideas for finer grain set acl controls

[Andrew Deason]

On Fri, 30 Oct 2009 10:27:23 -0500
Jim Rowan  wrote:

> >   fs: You don't have the required access rights on mayhem
> 
> I don't think you've solved this part of the problem.  I don't know  
> how to solve it, either.
> 
> Since the restrictive policy on adding ACLs is evaluated at the time  
> that the ACL is modified, and the membership of the super-group can
> be modified either before or after that event, this approach isn't
> going to result in any reasonable level of assurance that the ACLs
> are enforcing the intended policy (regarding access to the
> filesystem). It seems that as long as supergroups are in use in the
> cell, this is a potential hole.
> 
> In fact, this same issue exists with respect to individual members
> of a normal group as well.  (A policy preventing people from giving
> jane write access to some object would be circumvented if jane was
> added after the fact to a group that is allowed to be given write
> access to that object.)

There is a way around this. This isn't a security hole; you just
restricted the wrong thing (I got this wrong for awhile, too).

If you want to prevent everyone in project:mayhem from getting idwka
rights, you don't set the ACL policy to prevent people from setting
'project:mayhem idwka'. Instead, you give project:mayhem negative idwka
rights on all directories in the volume, and then set the ACL policy
such that users cannot take away the negative rights.

Therefore, the 'volume ACL policy' method is capable of doing everything
that the 'volume-level ACL overlay' method that Jeffrey (and later, I)
described, I believe. There are still pros and cons of each method; I'll
try to get something together to illustrate them.

-- 
Andrew Deason
adea...@sinenomine.net

___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

[OpenAFS] Re: Ideas for finer grain set acl controls

[Andrew Deason]

On Fri, 30 Oct 2009 13:20:12 -0400
Jeffrey Altman  wrote:

> To address the use case properly there needs to be the ability to
> apply additional sets of ACLs controlled entirely by the
> administrator. Positive ACLs that give privileges that cannot be
> restricted and negative ACLs that restrict privileges that cannot be
> granted.  These would have to be enforced by the file server at
> access time.  This ensures that changes in group membership do not
> bypass the administrator set permissions.

So, after having thought about this, I like general direction of
something like a volume-level administrator-set ACL, but it doesn't
quite work in two specific cases. That is, we don't really have a way to
specify, in an ACL, negative rights specifically for the anonymous user,
or specifically for someone who gets rights via only system:authuser.
Obviously, specifying negative rights for s:anyuser/authuser will just
remove rights for everybody.

For the s:anyuser case, we could allow you to specify 'anonymous' in the
volume ACL (why do we not allow this in normal ACLs, anyway? just
limitations of ptserver return codes?), which would allow you to take
away rights specifically from unauthenticated access. However, I can't
think of any way to do something similar for the s:authuser case.

My current thinking of a way around this is to have a volume-level ACL
that is just applied after any regular ACL, but also have a special case
for s:anyuser/authuser (and any system:authu...@* groups). In these
special cases, instead of adding them to the negative part of a
volume-wide ACL, you limit the acquired rights when you encounter that
group in a positive ACL entry on a directory.

That probably wasn't clear, so let me try an example. To prevent people
from giving write access to project:mayhem on volume user.rpaulson,
you'd do someting like

 vos setacl -vol user.rpaulson -acl project:mayhem idwka -neg

So whenever access is computed from an ACL, you also apply the negative
ACL entry for project:mayhem, preventing idwka access.

To prevent people from giving write access to system:anyuser on volume
user.rpaulson, you'd do something like

 vos restrictacl -vol user.rpaulson -id system:anyuser -maxrights rl

Now, whenever access is computed from an ACL, if the ACL user entry
matches system:anyuser (-101), we logically AND the rights in that entry
with 'rl', so you cannot give system:anyuser any rights besides rl. This
method would be applicable to groups like s:anyuser, s:authu...@*, and
probably host IP groups.

Does this make everyone happy? A clearer proposal (and an improved
interface) will need to be written to explicitly define all of this
stuff, but this is my general idea.

-- 
Andrew Deason
adea...@sinenomine.net

___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

[OpenAFS] Re: Ideas for finer grain set acl controls

[Andrew Deason]

On Sat, 31 Oct 2009 20:29:53 +0100
Sergio Gelato  wrote:

> * Jeffrey Altman [2009-10-30 13:20:12 -0400]:
> > To address the use case properly there needs to be the ability to
> > apply additional sets of ACLs controlled entirely by the
> > administrator. Positive ACLs that give privileges that cannot be
> > restricted and negative ACLs that restrict privileges that cannot
> > be granted.  These would have to be enforced by the file server at
> > access time.  This ensures that changes in group membership do not
> > bypass the administrator set permissions.
> 
> Even then, the devil lies in the details. I see no difficulty in
> having such additional ACLs work globally or with volume granularity,
> and this would be enough to express simple policies such as "no wida
> rights anywhere in the cell for system:anyuser"; but if one were to
> set such an additional ACL only on a user's public_html directory,
> what is there to keep the user from renaming directories? 

Relaxing the retrictions on a subset of volume data is impossible to do
sensibly, unless we do something like storing the paths (as strings)
from the volume root for directories we don't enforce. That sounds like
a scalability nightmare to me.

Personally, I think it's reasonable for this to be at volume
granularity. If you relax restricitons on a vnode inside the volume,
that vnode could go anywhere. So, what you're really saying is "you get
1 directory where these restrictions don't matter, wherever that
directory is". That doesn't seem very useful.

To solve the specific problem you mentioned, I would say you just give
each user a separate volume for web space, and change the volume-level
ACL for that volume. In the particular case of webspace, that also has
the benefit of being able to mount the user web volumes somewhere more
logical in the hierarchy, and ensures you are actually accessing their
web volume. (I.e. you mount the volume at
/afs/localcell/user/$user/public_html, and
/afs/localcell/common/web/user/$user, or something like that)

-- 
Andrew Deason
adea...@sinenomine.net

___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

[OpenAFS] Re: Ideas for finer grain set acl controls

[Andrew Deason]

On Fri, 30 Oct 2009 13:20:12 -0400
Jeffrey Altman  wrote:

> Michael:
> 
> Thank you for this proposal.  I think you have misnamed it.  What
> you are proposing is not finer grained ACLs but ACL change control
> policies.

Well, the idea was that we were making the 'a' bit finer-grained, but I
think your point is well taken.

> To address the use case properly there needs to be the ability to
> apply additional sets of ACLs controlled entirely by the
> administrator. Positive ACLs that give privileges that cannot be
> restricted and negative ACLs that restrict privileges that cannot be
> granted.  These would have to be enforced by the file server at
> access time.  This ensures that changes in group membership do not
> bypass the administrator set permissions.

Agreed; Jim's objection looks correct (thanks for catching that), and
we'll probably need to do something like this instead.

My concern with something like this, at least if it's a volume-wide
setting, would be how we allow an administrator to override the policy
in specific cases (e.g. the admin wants to specify one directory as
allowing system:anyuser write access). Storing it in the ACL for the
overridden directory means changing the ACL format. But storing it in
the per-volume data makes me worry about scalability.

Or is such an 'override' functionality not really important? Another way
of allowing that would be to actually store the e.g. negative ACL entry
in all of the ACLs for the volume, and prevent normal users from
removing them... but that has the obvious downside of needing to modify
all of the ACLs.

-- 
Andrew Deason
adea...@sinenomine.net

___
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info