[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [suse-security] NFS over SSH

On Fri, 4 Jun 2004, January Weiner wrote:

> Hello,
> > >     1) problem with high UID's, we have UIDs >> 65535 and the mounted samba
> > >     shares do not get proper permissions
> > 
> > Haven't been a problem for a couple of years, as far as I can gather,
> > definitely shouldn't be for Samba 3.  Changed rather shortly after 
> > kernel 2.4 appeared supporting UiDs > 65535.  Haven't tested this 
> > myself, just did a quick google just now.
> > 
> > http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=59407
> Well.  Take a look at https://bugzilla.samba.org/show_bug.cgi?id=1234 .
> If I understand it correctly, there are still many programs which use
> __kernel_uid_t instead of uid_t or __kernel_uid32_t.  
> I agree -- it should not be a problem.  But it is. 

Yes.  You got me.  And I've verified that this is a problem with the 
3.0.2a which used to be provided on the suse ftp-server.  I wonder
whether a patched version is forthcoming, though it looks trivial 
enough to patch it yourself and compile - assuming the patch is good.

> > >     2) is it true that Samba does not support special files (like sockets),
> > >     thus rendering this file system unusable for the purpose of mounting
> > >     home directories to use e.g. with KDE (which needs to create sockets)?
> > 
> > Not true.  'Unix extension = yes' in smb.conf solves this, the problem 
> > with KDE is that it has odd (':' in particular) characters in filenames, 
> > this is solved by also setting 'mangled names = no'.  Gnome, on the
> > other hand, uses a file locking strategy which is broken with sambamount.
> > Setting an environment variable GCONF_LOCAL_LOCKS=1 for the user moves the
> > file locking to /tmp and makes Gnome useable, though the solution isn't
> > optimal.
> Thanks!  That are good news for us.  And what about directories exported
> from Windows?

Not tested, but the server file system lacks the attributes you want to 
see on your linux client so I can't see how it could work.  For providing 
disk to multiple platforms, your server should be running unix or linux.  
The rest (NFS, Samba, whatever) is just cosmetics.

> > >   Am I wrong?  What other possibilities are there?  
> > 
> > Someone suggested VPN, which can force the user to authenticate to get
> > an IP address - at which point IP security all of a sudden deserves to
> > contain the word "security" in it.
> :-)
> OTOH -- as far as I understand, VPN encrypts the whole private network
> traffic, which may or may not be a problem in terms of performance.

VPN is a concept.  It's not a protocol, and there's no one true VPN 
way of doing things.  There's a tunnel.  Whether you're running 
encrypted data, compressed data, encrypted compressed data or just 
raw data through depends on configuration and which VPN software
you go for.  There's overhead, but with raw data they should be 
negligible.  Here at UiB we're running pptp without encryption, but
don't ask me about configuration - not my field.
> I have played now with shfs for a couple of days.  Well, the code is maybe
> not very mature (I had to correct the high UID issue here as well), and the
> performance remains to be tested, but at least for some purposes it is
> really great, and it is by far the easiest solution to configure and use.
> And the really nice thing about is that you do not need to configure or
> install anything on the server side.

I like it when I can change things in one place - on a server - 
rather than running through hundreds of clients to make changes. 
But tastes differ, as do the level of influence one has on the 
server configurations.

> One of our PhD students worked in Bergen for some time -- he says it is
> great :-)))

Except, of course, that the Bioinformatics group here is running 
DeadRat linux. >:(

Bjørn Tore Sund           Phone:  (+47) 555-84894    Stupidity is like a
System administrator      Fax:    (+47) 555-89672    fractal; universal and
Math. Department          Mobile: (+47) 918 68075    infinitely repetitive.
University of Bergen      VIP:    81724
Support: system@xxxxxxxxx Contact: teknisk@xxxxxxxxx Direct: bjornts@xxxxxxxxx

Check the headers for your unsubscription address
For additional commands, e-mail: suse-security-help@xxxxxxxx
Security-related bug reports go to security@xxxxxxx, not here