Paul Howell <[EMAIL PROTECTED]> writes:
> IP addresses that appear in your protection server (afs 3.2)
> will be handled as system:authuser even if you're not klog'd
> yet.
>
> So you could have system:authuser set and not be authenticated
> but still execute programs in your bin directory, and not have
> system:anyuser set.
When I first read this message, I found it very surprising that hosts
with pts-defined IP addresses would receive the benefits of
system:authuser membership. I finally got around to testing this
today and it seems that the statement is (thankfully!) wrong.
I created a new subdirectory in a public part of my cell. The ACL was
simply 'system:authuser read'. The pts entry "158.98.0.0" had already
been created a long while back. I got on a machine in that subnet,
but didn't authenticate to AFS, and I wasn't able to get a listing of
the test directory. Then I created a group containing "158.98.0.0"
and placed it on the ACL. That *did* give me read access to the
directory. To convince myself of what was going on, I gave
system:authuser write access to the directory. I could still read the
directory, but couldn't create a new file in it, confirming that the
new group entry was being used instead of system:authuser.
It is quite possible that the original CMU implementation behaved
differently than is described here. What I tested was AFS 3.2a.
Joe Jackson,
AFS Product Support,
Transarc Corp.
