> I can see that further explanation on my part would be helpful. After
> discussing this with several people at Transarc, I'm convinced that
> the automatic membership in system:authuser is a bad idea. I'll try
> to show you what I mean. If you still don't agree, please send those
> additional details to the list or directly to me and I'll mull it over
> some more.
Although automatic membership in some group (system:authhost?) isn't.
If authuser is broken but a mechanism was provided so that hosts could
be authenticated to a standard group without using some wildcard group which
covers the entire cell, I wouldn't complain. Especially since a wildcard
now covers machines that aren't even in the pts database (AFS 3.2a).
This would give us a greater degree of control over how we can ACL
things (authhost vs. anyhost_on_a_net).
> Even if I convince the developers that the ptserver is behaving
> inappropriately, you don't need to worry about the safety of your
> data. First, the change will probably not be available until AFS 3.3
> is released. Assuming that you choose to install the new version, the
> permissions will become only more strict, never more permissive. That
> is, your licensed software won't instantly become readable to a larger
> than intended group of people.
>
>
> I don't like the current implementation because:
>
> 1) It changes meaning of system:authuser. I have grown rather
> accustomed to the idea that system:authuser membership is granted only
> to those who hold a valid token. It's name even stands for
> "authenticated user." With the current implementation, membership is
> granted to those who have tokens along with those who are on hosts
> defined in the PTS database. I admit that a user on a "known" host
> could be viewed as "more trustworthy" than the rest of your
> unauthenticated users, but I feel that adding them to system:authuser
> is overkill.
>
> 2) It removes some of the previously available protection combinations.
> I use the traditional system:authuser semantics to create an
> authenticated drop box. (Specifically, mail messages are delivered to
> me as uniquely named files in my ~/Mailbox subdirectory.) I have
> "system:authuser lik" on the ACL so that any authenticated user can
> insert new files, but not read any of them. Using authuser instead of
> anyuser guarantees that all the submissions are stamped with the id of
> the submitter. If there happens to be a host defined in the PTS
> database, users of that host can issue "unlog" and then drop off files
> using the "anonymous" id. If I wanted to allow for that possibility,
> I would have used "system:anyuser lik" on the ACL!
One way to do this is to make a wildcarded group that covers all
machines in your ptserver (I think 0.0.0.0 would do the trick). Then,
negative acl that group on the directory. Only users who are actually
klog'd will have rights to the directory, which is what you want.
Admittedly, this is not really intuitive.
> 3) It causes wildcard PTS entries to behave differently than specific
> PTS entries. When your host matches a wildcard entry, system:authuser
> membership is *not* conferred. Also, wildcard entries that appear
> directly on an ACL (instead of in a group which is on an ACL) are
> ignored whereas specific PTS entries are heeded. This inconsistant
> behavior will certainly cause a great deal of confusion.
True. This is only because you now allow hosts which are not in the
ptserver to gain rights by being wildcarded. AFS 3.2 did not do this
and it was more clear what was happening. In AFS 3.2, when a host
matched a wildcard entry you were sure that the host was actually in
the ptserver. Otherwise it wouldn't have matched the wildcard.
> I think we should change the ptserver so that specific PTS host
> entries don't work when placed directly on ACLs and don't grant
> system:authuser access to unauthenticated users.
As long as something like system:authhost was provided, I don't think
this would be a problem. People that like the current implementation
of authuser can just acl their dirs to both authuser and authhost.
> I think problems introduced by such changes are worth the trouble
> because:
>
> 1) The present behavior can be mimicked by adding system:authuser
> directly on all the ACLs that presently include the specific host
> address or a group containing the host address. It will be pain in
> the neck to fix all those ACLs, but in exchange I get my authenticated
> drop-box back.
>
> 2) As I mentioned above, the change only can only reduce the number of
> users who have access to the files in your cell. Increasing the
> readability of files would raise many concerns, but I want to move the
> other direction.
Its true that your proposal would not increase the readability of
files, but it would break anything that relies on the current level of
readability. A workaround which allows the current level of
readability level of files to continue (for hosts in the ptserver)
should be provided.
-Scott
