On 24 Jan 2018, at 14:31, Ximeng Guan wrote:
I would expect that a local user on 10.12.8.31, even without an AFS
token, would be able to "cd" into the top directory of the cell. But
in reality that does not happen. An unauthenticated user is denied of
access.
When I explicitly put "machinegrp rl" on the ACL of the cell's top
directory (root.cell), an unauthenticated user is indeed able to
access the AFS space.
This is not quite convenient, because to allow the user of that
specific machine to launch a license software installed in a certain
(deep) directory under AFS, for example
/afs/cellname/tools/vendors/abc/softwarexx/bin, we would have to
explicitly place "machinegrp l" on the ACL of the parent directories
of ./bin from /softwarexx all the way up to /cellname.
Then if we have another software and another machine group, we will
have to do the same again, and the ACL of our root.cell directory will
soon be populated with machine group entries. That does not seem to be
an elegant solution.
Well, one thing you could do is create one PTS group, add the individual
machine-groups to that common PTS group, and then use the the common PTS
group for permitting directories. And then when you get to a directory
which has to be permitted to just one of those machines (and not to any
other machine groups), you'd use the individual machine-group instead of
the common one.
I use IP-based permissions for a few things. In at least one case, it
looks like I created a single group, and then kept adding the IP
addresses as new entries in that one PTS group.
You might also have to logout and log back in again. I have a vague
memory that PTS groups are only evaluated at login time. I'm not sure
that works with machine-groups.
--
Garance Alistair Drosehn = [email protected]
Senior Systems Programmer or [email protected]
Rensselaer Polytechnic Institute; Troy, NY; USA
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
