[OpenAFS] Re: Supergroups and ACL inheritance
Thomas Smith
theitsmith@gmail.com
Fri, 25 Feb 2011 14:27:55 -0700
--0016363b8e5ad7a7d0049d220081
Content-Type: text/plain; charset=ISO-8859-1
On Thu, Feb 24, 2011 at 10:11 PM, Andrew Deason <adeason@sinenomine.net>wrote:
> On Thu, 24 Feb 2011 18:01:10 -0700
> Thomas Smith <theitsmith@gmail.com> wrote:
>
> > Groups:
> > * group0 - The primary group for office location "group0".
> > * group0:admins - Office administrations for "group0".
>
> I assume you added group0:admins to group0? You don't say that, but you
> mention supergroups... but it doesn't seem to be too relevant to this. A
> 'supergroup' is when you add a group as a member of another group; I'm
> not sure if that's what you meant. You do that by running something like
> 'pts addu group0:admins group0'.
>
When I think of "supergroups" I think of "nested groups"--simply having
groups within a group.
* http://docs.openafs.org/Reference/1/pts_creategroup.html
The command that I use to create such groups is this:
* pts creategroup -name group0:admins -owner group0
It seemed like a more logical way to organize group memberships and
established relationships between groups and sub-groups. But maybe my
understanding on this topic is a little off.
> You also probably don't want to name the groups that way. The colon in
> group names is a special delimeter, indicating that group0:admins is
> owned by group0 (iirc, pts will not let you create that group unless you
> specify it as owned by group0). So, members of group0 will be able to
> add and remove members to/from group0:admins. That doesn't seem like
> what you want.
>
Correct. This is not what I want. So I will need to change this.
> You could create a group called group0 and a group called group0.admins
> (or groups called group0.members and group0.admins), and have the admins
> 'own' the non-admin group. You can specify ownership via 'pts createg
> -owner' or 'pts chown'.
>
This is a good idea, but we have a tightly controlled user access policy, so
only certain people have the authority to approve changes to user accounts.
However, I do like the the naming scheme you suggested.
> > Directory Structure:
> > * /afs/domain/Offices/Group0/ with group permissions:
> > * * group0 rlidwk
> > * /afs/domain/Offices/Group0/Admins/ with group permissions:
> > * * group0:admins rlidwk
> > * * -neg group0 rlidwk
>
> You don't want negative permissions there. I've found, at least for me,
> negative permissions are rarely what you want to do. I'm assuming you
> want 'group0' people to be able to put stuff all over the Group0/
> directory, but only want group0:admins to have access to the 'Admins'
> directory?
>
Your assumption is correct.
What purpose does negative permissions serve if not to remove permissions
inherited from a higher level?
> Depending on how secure/strict you want this to be, I'd be a little wary
> of organizing the directories like this. No matter what you do, you will
> be allowing 'group0' members to do something like this:
>
> $ mv Admins .someotherdir
> $ mkdir Admins
>
> Since group0 have rights to move stuff around. And now 'Admins' will
> have permissions "group0 rlidwk". If an 'admin' doesn't notice and drops
> some file in there, all members of 'group0' will be able to access it.
>
I just tested this from a Windows computer using standard Windows commands
(ren, copy, xcopy, and renaming the directories through Explorer) and all
generated an Access Denied.
Is there another way I should try this? I would just like to understand this
scenario a bit more--my current directory structure will need some reworking
given what you're suggesting.
"ACL inheritence" doesn't happen much in AFS, if I'm understanding that
> term correctly. That is, the permissions you have or not have in parent
> directories don't really affect you in lower directories (except
> inasmuch as you can actually reach the lower directories). There are a
> few instances where you implicitly gain certain rights (if you are the
> owner of the root of a volume, if you are the owner of a file in
> 'dropbox' scenarios), but they are more special-case scenarios.
>
Here is my understanding of ACL inheritance in AFS.
/afs/domain: system:authuser l
/afs/domain/Offices/group0: group0 rlidwk (Note that group0 is a volume
mount point.)
In this situation, "system:authuser l" propigates /afs/domain's directory
structure--that is, every new directory will have the permissions
"system:authuser l".
However, this propagation doesn't cross volume boundaries. So, the
"system:authuser l" permission isn't applied to Offices/group0 by default.
As such, only the group "group0" will have any access to that.
In a similar vein, "group0 rlidwk" will be applied to all directories
created within the Offices/group0 volume.
I'm new to AFS and still learning, but this is my current understanding. Is
my understanding of ACL inheritance correct?
Thanks for your input Andrew. I will end up changing around a couple of
things as a result of your feedback.
--0016363b8e5ad7a7d0049d220081
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div class=3D"gmail_quote">On Thu, Feb 24, 2011 at 10:11 PM, Andrew Deason =
<span dir=3D"ltr"><<a href=3D"mailto:adeason@sinenomine.net">adeason@sin=
enomine.net</a>></span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); =
padding-left: 1ex;">
<div class=3D"im">On Thu, 24 Feb 2011 18:01:10 -0700<br>
Thomas Smith <<a href=3D"mailto:theitsmith@gmail.com">theitsmith@gmail.c=
om</a>> wrote:<br>
<br>
> Groups:<br>
> * group0 - The primary group for office location "group0".<b=
r>
> * group0:admins - Office administrations for "group0".<br>
<br>
</div>I assume you added group0:admins to group0? You don't say that, b=
ut you<br>
mention supergroups... but it doesn't seem to be too relevant to this. =
A<br>
'supergroup' is when you add a group as a member of another group; =
I'm<br>
not sure if that's what you meant. You do that by running something lik=
e<br>
'pts addu group0:admins group0'.<br></blockquote><div><br>When I th=
ink of "supergroups" I think of "nested groups"--simply=
having groups within a group.<br><br>=A0=A0=A0=A0 * <a href=3D"http://docs=
.openafs.org/Reference/1/pts_creategroup.html">http://docs.openafs.org/Refe=
rence/1/pts_creategroup.html</a><br>
<br>The command that I use to create such groups is this:<br><br>=A0=A0=A0 =
* <span style=3D"font-size: 11pt; font-family: Arial; color: rgb(0, 0, 0); =
background-color: transparent; font-weight: normal; font-style: normal; tex=
t-decoration: none; vertical-align: baseline;">pts creategroup -name group0=
:admins -owner group0</span><br>
<br>It seemed like a more logical way to organize group memberships and est=
ablished relationships between groups and sub-groups. But maybe my understa=
nding on this topic is a little off.<br>=A0</div><blockquote class=3D"gmail=
_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204,=
204, 204); padding-left: 1ex;">
You also probably don't want to name the groups that way. The colon in<=
br>
group names is a special delimeter, indicating that group0:admins is<br>
owned by group0 (iirc, pts will not let you create that group unless you<br=
>
specify it as owned by group0). So, members of group0 will be able to<br>
add and remove members to/from group0:admins. That doesn't seem like<br=
>
what you want.<br></blockquote><div><br>Correct. This is not what I want. S=
o I will need to change this.<br>=A0</div><blockquote class=3D"gmail_quote"=
style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 2=
04); padding-left: 1ex;">
You could create a group called group0 and a group called group0.admins<br>
(or groups called group0.members and group0.admins), and have the admins<br=
>
'own' the non-admin group. You can specify ownership via 'pts c=
reateg<br>
-owner' or 'pts chown'.<br></blockquote><div><br>This is a good=
idea, but we have a tightly controlled user access policy, so only certain=
people have the authority to approve changes to user accounts. However, I =
do like the the naming scheme you suggested.<br>
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8=
ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class=3D"im">
> Directory Structure:<br>
> * /afs/domain/Offices/Group0/ with group permissions:<br>
> * * group0 rlidwk<br>
> * /afs/domain/Offices/Group0/Admins/ with group permissions:<br>
> * * group0:admins rlidwk<br>
> * * -neg group0 rlidwk<br>
<br>
</div>You don't want negative permissions there. I've found, at lea=
st for me,<br>
negative permissions are rarely what you want to do. I'm assuming you<b=
r>
want 'group0' people to be able to put stuff all over the Group0/<b=
r>
directory, but only want group0:admins to have access to the 'Admins=
9;<br>
directory?<br></blockquote><div><br>Your assumption is correct.<br><br>What=
purpose does negative permissions serve if not to remove permissions inher=
ited from a higher level?<br>=A0</div><blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204);=
padding-left: 1ex;">
Depending on how secure/strict you want this to be, I'd be a little war=
y<br>
of organizing the directories like this. No matter what you do, you will<br=
>
be allowing 'group0' members to do something like this:<br>
<br>
$ mv Admins .someotherdir<br>
$ mkdir Admins<br>
<br>
Since group0 have rights to move stuff around. And now 'Admins' wil=
l<br>
have permissions "group0 rlidwk". If an 'admin' doesn'=
;t notice and drops<br>
some file in there, all members of 'group0' will be able to access =
it.<br></blockquote><div><br>I just tested this from a Windows computer usi=
ng standard Windows commands (ren, copy, xcopy, and renaming the directorie=
s through Explorer) and all generated an Access Denied.<br>
<br>Is there another way I should try this? I would just like to understand=
this scenario a bit more--my current directory structure will need some re=
working given what you're suggesting.<br></div><br><blockquote class=3D=
"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rg=
b(204, 204, 204); padding-left: 1ex;">
"ACL inheritence" doesn't happen much in AFS, if I'm unde=
rstanding that<br>
term correctly. That is, the permissions you have or not have in parent<br>
directories don't really affect you in lower directories (except<br>
inasmuch as you can actually reach the lower directories). There are a<br>
few instances where you implicitly gain certain rights (if you are the<br>
owner of the root of a volume, if you are the owner of a file in<br>
'dropbox' scenarios), but they are more special-case scenarios.<br>=
</blockquote><div><br>Here is my understanding of ACL inheritance in AFS.<b=
r><br>/afs/domain: system:authuser l<br>/afs/domain/Offices/group0: group0 =
rlidwk (Note that group0 is a volume mount point.)<br>
<br>In this situation, "system:authuser l" propigates /afs/domain=
's directory structure--that is, every new directory will have the perm=
issions "system:authuser l".<br><br>However, this propagation doe=
sn't cross volume boundaries. So, the "system:authuser l" per=
mission isn't applied to Offices/group0 by default. As such, only the g=
roup "group0" will have any access to that.<br>
<br>In a similar vein, "group0 rlidwk" will be applied to all dir=
ectories created within the Offices/group0 volume.<br><br>I'm new to AF=
S and still learning, but this is my current understanding. Is my understan=
ding of ACL inheritance correct?<br>
<br>Thanks for your input Andrew. I will end up changing around a couple of=
things as a result of your feedback.<br></div>
</div>
--0016363b8e5ad7a7d0049d220081--