[Samba] Automount homes via smb question

[Andrew Bartlett]

On Wed, Nov 05, 2003 at 11:01:14PM -0800, Mike Ely wrote:
> On Nov 5, 2003, at 10:51 PM, Andrew Bartlett wrote:
> 
> > On Wed, Nov 05, 2003 at 10:26:48PM -0800, Mike Ely wrote:
> >>
> >>>>> Also, we have the problem of
> >>>>> special files over CIFS - your Win2k server probably will not like
> >>>>> attemptes to create symbolic links.
> >>>>>
> >> Hmm.  I don't like where this leads... I'm thinking in particular of
> >> /tmp... is there no CIFS interface to create windows "shortcuts" or 
> >> are
> >> those so very different from symlinks?
> >
> > They are - steve french was looking at coming up with come method to
> > represent such 'special files', but the 'correct' semantics is rather
> > unclear...
> >
> > (It's also an issue for Samba servers, as we block certian symlinks,
> > in particlar the one to /tmp that kde makes on startup).
> >
> > Andrew Bartlett
> 
> Is this blocking in place for a particular security issue, or is there 
> some kind of weird race condition where you have local apps talking to 
> a local /tmp over a symlink that resides on a remote volume?  'Scuse my 
> ignorance - I'm trying to understand some core issues here.

It's a matter of 'which /tmp'? 

Should it be /tmp on the server - which is how a symlink would
normally show up, or /tmp on the client - in which case samba should
refuse the open, and cause the client to read the link.  Could a
client create a link to /etc/passwd (for sake of argument), then
reconnect as 'windows' and read it, despite the fact that the the /etc
directory was not shared.  Personally, I think we should allow this,
as long as the admin tells us so (by smb.conf directive), given that
there are Samba servers that allow direct login to the filespace
anyway.  But on servers without shell logins, it is a security hold.
(The other way to prevent such a security hole is the 'wide links'
directive, but this is slow and racy).

Andrew Bartlett