Excerpts from mail: 27-Apr-93 Re: PAG Instructions, Please
Joseph_Jackson@transarc. (4011)
> 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.
What happens when we migrate to DCE/DFS? I've heard that under DCE,
machines are objects that can authenticate themselves. Can such machine
objects be given access rights on DFS ACLs? If so, it seems that this
is the logical mapping for those of us who are using IP addresses on
ACLs to control access to licensed software under AFS. Would the DCE
equivalent of system:authuser (if there even is such a thing) include
authenticated machines? If so, perhaps AFS IP addresses on ACLs should
behave the same.
Keith Gorlen
National Institutes of Health
Bethesda, MD 20892
Phone: (301) 496-1111
FAX: (301) 402-2867
Internet: [EMAIL PROTECTED]
