Re: cifs multiuser mode and per session treatment

["Aurélien Aptel" <aaptel@suse.com>]

Hi Björn,

Björn JACKE <bj@SerNet.DE> 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)