dynamic context transitions

[Andrew Bartlett]

On Tue, 2004-11-09 at 01:42, Russell Coker wrote:
> On Tuesday 02 November 2004 07:25, Stephen Smalley <sds at epoch.ncsc.mil> wrote:
> > >  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.  Not to mention that this no doubt has a significant
> > cost.
> 
> The cost is only for open, creat, link, symlink, unlink, mkdir, and rmdir 
> operations, which usually aren't that performance critical.  The few 
> applications for which such operations are performance critical (Maildir 
> format mail spool and old style INN news spool) are unlikely to be used over 
> SMB.
> 
> As for allowing operations, the parent must be permitted to receive file 
> handles from the child and to have read/write access to all files that the 
> child processes may open.

May I be so unfortunate as to introduce some sanity into this
discussion?

This is a very nice discussion about how you might build a new
file-server, for a new protocol, without existing clients, but back in
the real world, with a real-world source-code base, I really wonder how
all this is actually intended to work.

A few things need to be considered about the new design: 

- Will it work?
Locking semantics in unix are a real pain, and there are particular
issues that arise from process contexts that such a proposal may break.

- Will anybody other than SELinux use it?
If nobody other than SELinux uses a part of the code, it will bitrot, or
worse.

- Will it be portable?
I'm told that file-descriptor passing between processes is particularly
non-portable, and this would appear to preclude the first point.

- Will SELinux be willing to provide and maintain a long-term patch for
this functionality?

I can't imagine why, given the first two points, we would want to
introduce the performance overhead of a fork()ed child per user context
(which can be for every share, and every user on that share, and there
was a proposal for every operation...) into every Samba installation.  

I'll assert (by hand-waving) that basic file operations, and not
read()/write() are actually performance critical.  Do you know how often
Samba calls stat() and readdir()?

On the other hand, adding an extra #ifdef to become_user() and friends
is a small, maintainable solution.  It just may not fit with the SELinux
world view.

Andrew Bartlett

-- 
Andrew Bartlett                                 abartlet at samba.org
Authentication Developer, Samba Team            http://samba.org
Student Network Administrator, Hawker College   abartlet at hawkerc.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20041114/2cf841ea/attachment.bin