Hi Björn, Björn JACKE <bj@xxxxxxxxx> writes: > cifs.upcall might need some tuning to make use of a session keyring but even if > that would be done, there is still one important limitation left to solve: cifs IIRC cifs.upcall uses the session keyring already. > multiuser SMB connections should also be initiated per session, same like the > keyring. Currently the cifs SMB connections are accessible also from other all > sessions. That needs to be implemented indeed. > For example if I kinit a ticket, access a multiuser cifs mount successfully (so > that the smb session is initiated), then kdestroy my ticket, log in to the > machine again to open a new session, and then access the multiuser cifs mount > from there, this is currently successful. For a cifs multiuser mount with per > session limitation, this access should be denied accordingly. I think I understood. In terms of implementation each cifs mount stores a dictionnary mapping uid to TreeCon (it's the tlink rb-tree, see cifs_sb_tlink(), tlink_rb_search(), etc). I think it should just be a matter of storing the session id as the key in the tlink rb-tree instead of uid (we use fsuid actually). This way when a new session does a syscall on the mount, the lookup will fail, it will try to create a new tlink, and fail unless there is the krb stuff in the keyring. But are you sure root cannot "enter" an existing user session? I think I've done it for screen sessions in the past... If yes, would this make this per-session smb session pointless or is there still some value? Cheers, -- Aurélien Aptel / SUSE Labs Samba Team GPG: 1839 CB5F 9F5B FB9B AA97 8C99 03C8 A49B 521B D5D3 SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg, DE GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 247165 (AG München)
