-----Your message-----
> 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.
>
-----End of your message-----
Paul's statement is correct in some AFS versions. If a machine has a pts
entry it will act as authuser. Even if the individual user is not klog'd,
s/he will have authuser rights if s/he is on a machine with a pts entry for
its IP address.
We are running the AFS 3.2 ptserver here.
For example:
limbo% mkdir afstest
limbo% fs sa afstest system:authuser rl system:anyuser none
limbo% cat > afstest/blah
Wow, it works.
limbo% fs sa afstest sdawson none
limbo% fs la afstest
Access list for afstest is
Normal rights:
system:administrators rlidwka
system:authuser rl
limbo% rlogin litotes
*** /etc/motd login message deleted ***
litotes% /usr/afs/bin/tokens
Tokens held by the Cache Manager:
[ 1] --End of list--
litotes% cat afstest/blah
Wow, it works.
litotes% /usr/afs/bin/fs la afstest
Access list for afstest is
Normal rights:
system:administrators rlidwka
system:authuser rl
litotes%
The reason is that when the HostCPS entry is built, the list of groups
which the machine belongs to is built the same as it is for users. One of
the steps in the process is to add the user/machine to the system:anyuser
and system:authuser groups.
This is in the AFS 3.2 ptserver code for sure. I don't know how the 3.2a
ptserver handles it.
-Scott
