[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">&lt;<a href=3D"mailto:adeason@sinenomine.net">adeason@sin=
enomine.net</a>&gt;</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 &lt;<a href=3D"mailto:theitsmith@gmail.com">theitsmith@gmail.c=
om</a>&gt; wrote:<br>
<br>
&gt; Groups:<br>
&gt; * group0 - The primary group for office location &quot;group0&quot;.<b=
r>
&gt; * group0:admins - Office administrations for &quot;group0&quot;.<br>
<br>
</div>I assume you added group0:admins to group0? You don&#39;t say that, b=
ut you<br>
mention supergroups... but it doesn&#39;t seem to be too relevant to this. =
A<br>
&#39;supergroup&#39; is when you add a group as a member of another group; =
I&#39;m<br>
not sure if that&#39;s what you meant. You do that by running something lik=
e<br>
&#39;pts addu group0:admins group0&#39;.<br></blockquote><div><br>When I th=
ink of &quot;supergroups&quot; I think of &quot;nested groups&quot;--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&#39;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&#39;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=
>
&#39;own&#39; the non-admin group. You can specify ownership via &#39;pts c=
reateg<br>
-owner&#39; or &#39;pts chown&#39;.<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">
&gt; Directory Structure:<br>
&gt; * /afs/domain/Offices/Group0/ with group permissions:<br>
&gt; * * group0 rlidwk<br>
&gt; * /afs/domain/Offices/Group0/Admins/ with group permissions:<br>
&gt; * * group0:admins rlidwk<br>
&gt; * * -neg group0 rlidwk<br>
<br>
</div>You don&#39;t want negative permissions there. I&#39;ve found, at lea=
st for me,<br>
negative permissions are rarely what you want to do. I&#39;m assuming you<b=
r>
want &#39;group0&#39; people to be able to put stuff all over the Group0/<b=
r>
directory, but only want group0:admins to have access to the &#39;Admins&#3=
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&#39;d be a little war=
y<br>
of organizing the directories like this. No matter what you do, you will<br=
>
be allowing &#39;group0&#39; 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 &#39;Admins&#39; wil=
l<br>
have permissions &quot;group0 rlidwk&quot;. If an &#39;admin&#39; doesn&#39=
;t notice and drops<br>
some file in there, all members of &#39;group0&#39; 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&#39;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;">

&quot;ACL inheritence&quot; doesn&#39;t happen much in AFS, if I&#39;m unde=
rstanding that<br>
term correctly. That is, the permissions you have or not have in parent<br>
directories don&#39;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>
&#39;dropbox&#39; 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, &quot;system:authuser l&quot; propigates /afs/domain=
&#39;s directory structure--that is, every new directory will have the perm=
issions &quot;system:authuser l&quot;.<br><br>However, this propagation doe=
sn&#39;t cross volume boundaries. So, the &quot;system:authuser l&quot; per=
mission isn&#39;t applied to Offices/group0 by default. As such, only the g=
roup &quot;group0&quot; will have any access to that.<br>
<br>In a similar vein, &quot;group0 rlidwk&quot; will be applied to all dir=
ectories created within the Offices/group0 volume.<br><br>I&#39;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--