dynamic context transitions
abartlet at samba.org
Sun Nov 14 01:18:24 GMT 2004
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
> 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
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
- 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
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
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
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20041114/2cf841ea/attachment.bin
More information about the samba-technical