[OpenAFS] Re: OpenAFS and AD trusts
Thu, 15 Sep 2011 13:04:39 -0400
Well yes, the group system:email@example.com does exist:
[root@afs1c afs]# pts listentries -groups -noauth
Name ID Owner Creator
system:administrators -204 -204 -204
system:backup -205 -204 -204
system:anyuser -101 -204 -204
system:authuser -102 -204 -204
system:ptsviewers -203 -204 -204
system:firstname.lastname@example.org -207 -204 2
Also, system:email@example.com was created by 2, which is me as admin, so
it was there before my aklog as foreign user. Is the foreign-realm
group something that needs to be set in advance, or is that part of the
automatic registration thing?
And yes, as foreign user firstname.lastname@example.org, I lack the "rlidwka" rights to
the cell directory /afs/afs1.bedrock.iu.edu. All I can do is "rl"
Andrew Deason wrote:
> On Thu, 15 Sep 2011 11:10:40 -0400
> Danko Antolovic <email@example.com> wrote:
>> However, this does not let me touch the files in the cell. Trying to
>> add the foreign-realm group to the directory ACL, like this:
>> [root@afs1c afs]# fs setacl -dir /afs/afs1.bedrock.iu.edu -acl
>> system:firstname.lastname@example.org rlidwka
>> does not seem to work, and just adds the group system:authuser to the
>> ACL once more:
> To be clear: this is supposed to work (and does for me, here). Have you
> been changing around the names or IDs of these groups?
> system:email@example.com doesn't appear to exist anymore.
> This would suggest something along the way is screwing up the id<->name
> mapping, but that may not necessarily prevent the actual access from
> working. Are you actually lacking those rights? (that is, when trying to
> do one of those operations)
> You can look at a network dump to verify what names are going across the
> wire, to see if the setacl and listacl requests are what you think
> they are. You don't need to be familiar with the protocol or anything;
> it should be pretty easy to see where the acl data is (it is transmitted
> in the clear, when 'fs crypt' is turned off).