In message <[email protected]>,Alberto M ancini writes: >> The current implementation only looks at the keyring if it can't determine >> the PAG from the process's groups. If it has to use the keyring, then it >> attempts to set the process's group list, so that the group is used for all >> future lookups. > >Is this for performance reasons (or for something i do not see) or >is just an implementation side-effect ?
i am surpised the behavior is this way. probably came about due to the way i wrote the code. i added pag support to get check if the group check failed. then i added the feature to put the pag groups back into the list (so that legacy applications dependent on this worked). i suppose we should really check the keyring first and fall back to the groups. see PagInCred(). just make the LINUX_KEYRING_SUPPORT stuff happen first. >This really forbid having a pag-per-thread (at least with POSIX threads >where groups are shared). right. >First of all, to go ahead, I should change this (looking at the code this >seems not terribly tricky) but, is this change something that can be >reasonably applied to ``some`` openafs upstream ? > >Responding to Derrick's question ``For yourself, or to us?'' > >I am writing this code and if there is some convergence on the >interface the new setpag should have I can volunteer to write (an rewrite) >the code for inclusion. > >The facts seems to be: > >Adding an argument to AFSCALL_SETPAG is ``no way`` (Jeff) >A new ioctl to pioctl can be a choice (Chas) yeah, i didnt think anyone would like changing setpag(). anything we probably just need a variation of setpag() (in LINUX/osi_groups.c) that has an extra flag to indicate the session keyring or the thread keyring. this would also need to flag install_session_keyring, or just simply the keyring of interest to install_session_keyring() and rename to install_keyring(). calling it a pag is a misnomer though at this point. oh well. _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
