Paul Howell <[EMAIL PROTECTED]> writes:
> Joe,
>
> Woa!
>
> Please don't fix something that isn't broken. Perhaps not
> enough is understood about IP addresses/PTS/ACLs, but please
> don't change anything.
>
> We've come to an understanding as to how this all works and we
> are trying to use it to keep licenesed software from being
> accessible to the world when we announce our cell.
>
> My own feelings are that IP addresses in the pt server being
> recognized as system:authuser is a good thing.
>
> I can provide with additional details if you'd like.
Paul,
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.
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!
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.
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.
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.
I guess that covers it. If anyone has further comments, I'd like to
hear them.
Joe Jackson,
AFS Product Support,
Transarc Corp.
