In message <[EMAIL PROTECTED]>,David Howells writes: >> > Session Keyring >> > -3 --alswrv 0 0 keyring: _uid_ses.0 >> > 2 --alswrv 0 0 \_ keyring: _uid.0 >> > 29391168 ----s--v 0 0 \_ afs_pag: _pag >> > > >What I'm pointing out in the above key ring dump is the fact that the _pag key >is attached to the _uid_ses.0 keyring (the root user default session keyring).
ah right i see now. sorry, i have come in a bit late on this. i would guess this an oversight on my part. the afs install_session_keyring() isnt checked for failure. so if it does fail and there happens to be a session keyring already present it will get the pag. this is not the intended behavior. of course pagsh() cant tell you it failed either. still afs shouldnt set a pag if it didnt manage to create a session keyring. >> the afs pag is always uid = 0 so that users cant modify the key and discern >> its contents. > >Can you achieve that by just not providing read and update ops for the key? i dont have read or update ops now. i dont think this would be sufficient since the afs_pag key type still has to have an instantiate op which the user could call. i dont want users creating session keyrings and arbitrary pags trying to join existing pags. particulary since pags are given out in a serial fashion. (someone should fix this). _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
