[OpenAFS] "group prefix doesn't match owner"
Mon, 03 May 2010 20:38:51 -0700
Derrick Brashear <email@example.com> writes:
> On Mon, May 3, 2010 at 11:23 PM, Russ Allbery <firstname.lastname@example.org> wrote:
>> Users who create a workgroup named shadow:something and then go to AFS
>> and wonder why fs setacl . shadow:something all doesn't work are
>> unlikely to be easily patched to track by ID instead.
> they should probably avoid chowning the group away between steps a and b.
They're not the ones doing the chowning, and the problem runs much deeper
than chown. AFS makes it extremely hard to have a group named
bar:something and owned by foo, and I think this is a bug. We've run into
this bug a bunch of different ways over the years.
The most recent way we had this problem was:
* We have a system that synchronizes groups from LDAP into AFS PTS.
* We don't want that system to have to run as system:administrators
(principal of least privilege).
* We do want that system to be able to create and manage groups under
workgroup:*, but we'd also like it to be able to *manage* any other
group that someone decides to put under its management. The task of
putting the group under its management can be done by
Unfortunately, there's no way of doing that last bit without renaming the
PTS groups, since if you change the owner, the group magically changes
names. Which can invalidate other places where people are used to using
the current PTS group name, and also tends to give the groups random and
unhelpful names since it cuts off the first part before the colon, which
is often important information about what the group is for.
Other places where we've run into this was when we wanted to create a set
of groups named cvs-committers:* and manage them all as
system:administrators. I ended up having to create a fake (and useless)
cvs-committers group to prevent the groups from constantly getting
magically renamed to system:* instead. Likewise for organization groups;
I end up having to create dummy parent groups matching the prefix that I
don't want and don't want to ever use.
I see no purpose in this restriction, at least if the action is being
performed by system:administrators, and think it should die.
Russ Allbery (email@example.com) <http://www.eyrie.org/~eagle/>