From: "Björn JACKE" <bj@SerNet.DE>
To: linux-cifs@vger.kernel.org
Subject: cifs multiuser mode and per session treatment
Date: Fri, 13 Dec 2019 13:14:52 +0100 [thread overview]
Message-ID: <20191213121452.GA12253@sernet.de> (raw)
Hi,
I'm trying to use cifs vfs with multiuser mode in a way, that it's not possible
for people with root privileges to hijack other users' SMB sessions of a
multiuser mount.
For authentication I use krb5. The first problem to solve is that root users
can access the ccache files of any user who is authenticated and has a
/tmp/krb5cc_%{uid} file. This problem can be solved with a ccache type of
session keyring (default_ccache_name = KEYRING:session:%{uid} in krb5.conf).
This is doing exactly what I expect, you can get a ticket but if you log in to
the server once more you will not have that ccache and thus also other users
logging in and trying to "su" to a different user will not have access to the
keyring of the user.
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
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.
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.
What do you cifs vfs experts think about adding such a "per session" mode for
the multiuser mode?
Thanks
Björn
next reply other threads:[~2019-12-13 20:36 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-13 12:14 Björn JACKE [this message]
2019-12-16 11:38 ` cifs multiuser mode and per session treatment Aurélien Aptel
2019-12-17 10:07 ` Björn JACKE
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191213121452.GA12253@sernet.de \
--to=bj@sernet.de \
--cc=linux-cifs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.