Luke Kenneth Casson Leighton
lkcl at lkcl.net
Wed Jun 2 12:45:23 GMT 2004
just wanted to correct some things and also to apologise for having a
now that i recall that it is the SMBsessionandX that needs to be
de-multiplexed (not the SMBtconX unless, like as tridge says,
the SMBsesssetupX is skipped as with share-level security) i should
make this clear.
however, my faulty memory, has, i believe, no impact on the
solution: the solution remains the same (albeit slower than
it could be, and clumsy).
under which circumstances, yes, tridge is right: 1) the TconX
behaviour is irrelevant (for seteuid()) and 2) the present
samba(4) SMB client NT-VFS plugin's behaviour is less than ideal
(in that it creates new tcp connections for every single TconX
... but it will work, and provide the required security semantics.
in the back-end se-samba(3) all that should be required is to run
pam_selinux.so. and the front-end se-samba(4) just use the new
at a later date, improvements in the SMB NT-VFS proxy plugin can
be made (see cliffs or samba tng libsmb code for example, somewhere,
i promise!, of modified libsmb which can do multiple tconXes over
a single TCP connection).
On Wed, Jun 02, 2004 at 08:33:06AM +1000, tridge at samba.org wrote:
> > It's a), everything is done via a single tcp connection. One reason is that we
> > want to mirror the behaviour that the server we proxy towards gives us as
> > closely as possible. Separate smb connections give a difference that might have
> > influence on the server's behaviour.
> Nope, the we open a new connection for each tree connect in that
> It really doesn't matter though, as unless I have completely
> misunderstood se-linux, the TConX behaviour is completely irrelevant
> for the seteuid() problem that se-linux faces. All TConX does is
> establish a connection to a new directory (ignoring ancient share
> level security setups).
More information about the samba-technical