On Tue, 2014-03-18 at 09:29 -0400, Jeffrey Altman wrote: > > - of course you can't access membership listing and other ptserver > > stuff. > > Fyi, self service group membership management is one of the hallmarks of > AFS. Restricting access to system:authuser + foreign is necessary if > you wish to permit users to define and manage personal groups.
However, this is much easier to do in the ptserver, which owns the PRDB and already uses PRDB lookups as part of its authorization process, than it would be in the volserver or vlserver, which have no relationship with the ptserver (and for which requiring such a relationship could be operationally undesirable). > Its not that complicated unless you want to set separate permissions for > each remote Kerberos realm. If the levels are authuser localonly and > authuser remote then the difference is a test for membership in > system:authuser or a test for a non-anonymous AFS ID. A volserver or vlserver cannot easily test for membership in system:authuser, and does not know the client's AFS ID. Changing this would be a _much_ more complex patch, since it would require something analogous to the fileserver's hpr package. > > I also have some new questions, maybe a bit controversial: > > > > - would anything break if we wouldn't return the volume name when the > > GetVolumeByID is used if you're unauthenticated? > > Yes. Cache managers that lookup volume group data by ID would not be > able to hash the data by the name. This would result in multiple > volume group entries for the same volume group in the Windows cache > manager. There would be negative impacts on volume callback processing. Cache managers are supposed to look up volume group data by name, not ID. This is why VL_GetEntryByName*() support lookups of "names" that look like volume IDs. The UNIX cache manager behaves this way and always has (or at least, it has since there _was_ a separate volume location service). Does Windows do this differently? > Reviews should be performed in Gerrit. Reasonably complete patches should be submitted to Gerrit for review and integration. Design discussion is more appropriate on this mailing list than in review comments in Gerrit, which are terrible as a general-purpose discussion medium. This thread is just crossing the boundary from one to the other, _if_ we assume general agreement on the scope of the change (for example, not adding features that would require PRDB lookups in the volserver or vlserver). However, I should point out that discussions regarding making semantic changes to RPCs, _especially_ when those RPCs are used by cache managers and other AFS client implementations, belong on the afs3-standardization list, not here. The readership of the two lists is not the same, and a message sent there raising the possibility of locking down RPCs that may be used by clients could well raise objections that would not be mentioned here. For example, the author of afscp, which was mentioned earlier in this thread, follows that list, but I don't think he pays attention to this one nearly as often. -- Jeff _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
