se-samba

[Luke Kenneth Casson Leighton]

just wanted to correct some things and also to apologise for having a
bad memory.

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
as _well_).

... 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
proxy plugin.


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).

l.

On Wed, Jun 02, 2004 at 08:33:06AM +1000, tridge at samba.org wrote:
> Volker,
> 
>  > 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
> backend.
> 
> 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).