dynamic context transitions
Luke Kenneth Casson Leighton
lkcl at lkcl.net
Mon Nov 1 21:00:39 GMT 2004
On Mon, Nov 01, 2004 at 03:25:21PM -0500, Stephen Smalley wrote:
> On Mon, 2004-11-01 at 15:35, Luke Kenneth Casson Leighton wrote:
> > no there is no reason why [a helper application should] not [be used].
> > i am not sure if the simple solution [that andrew and russell
> > came up with] was fully enumerated: it involves exec'ing a
> > per-user helper application which does a setuid.
> > the helper application opens files as-and-when they are needed,
> > [and also does mkdirs? and rmdirs?] and then passes the file
> > descriptor over a unix-domain-socket to the smbd process,
> > which NEVER itself does file opens under a user context.
> > i believe it then no longer becomes necessary for smbd to
> > call become_user().
> Except that SELinux mediates access to file descriptors upon transfer
> via local socket IPC as well as attempted use for read/write, so SELinux
> is still going to apply a permission check to the parent smbd process in
> that situation.
that i would expect.
> Not to mention that this no doubt has a significant
that i was not expecting.
... which leaves my original idea as a viable option, and it is one
that fits the "exec()" principle.
the "front-end" proxy smbd process [doing NT-style network-based
authentication] i.e. a "Samba 4" server with the example
VFS SMB-proxy used in a live production environment, and a
"back-end" "Samba 3.0.X" server doing the actual file access.
if speed is of the essence [the overhead of an intermediate TCP
connection is considered to be non-trivial] then an additional
communication mechanism, just like MySQL does and just like
X does, can be added: a unix-domain-socket to provide a
communication path between the front-end and back-end servers.
the front-end smbd process running in smbd_t context, the
back-end running in smbd_user_t context, never the twain
several front-end smbd processes would need to be triggered -
one for each SMB user context - something that i believe the
"Samba 4" VFS SMB-proxy plugin already does [by default /
if the cost of the [permanently established] link between the
front-end and back-end is expensive on an selinux system [due
to exactly the same mediation that stephen mentions above],
how about using shared memory instead?
it would require a little bit of design thought [or researching
for existing libraries] - a packet-based transport in shared
memory that to all external intents and purposes looked like
a socket (odd!)
you don't have to BE MAD | this space | my brother wanted to join mensa,
to work, but IT HELPS | for rent | for an ego trip - and get kicked
you feel better! I AM | can pay cash | out for a even bigger one.
More information about the samba-technical