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

Re: Samba or NFS



On 06/03/11 at 07:41pm, Axel Freyn wrote:
> Hi,
> On Fri, Jun 03, 2011 at 01:17:35PM -0400, William Hopkins wrote:
> > On 06/03/11 at 12:43pm, John A. Sullivan III wrote:
> > > ----- Original Message -----
> > > From: "Jari Fredriksson" <jarif@iki.fi>
> > > To: debian-user@lists.debian.org
> > > Sent: Friday, June 3, 2011 11:58:15 AM
> > > Subject: Re: Samba or NFS
> > > 
> > > 3.6.2011 18:08, Dan kirjoitti:
> > > > Hi,
> > > > 
> > > > I have two linux servers. One file server (debian) that is running
> > > > samba and one application server (redhat). I would like to mount the
> > > > shares of the file server in the application server. The problem is
> > > > that the usernames are very different. Samba is already running and
> > > > easier to set-up. NFS seems to be more difficult to set-up and also
> > > > there are more security issues.
> > > > 
> > > > Which are the advantages of NFS over Samba (cifs) other than the
> > > > symbolic links. I read that even some people prefer samba over NFS to
> > > > connect Unix to Unix.
> > > > 
> > > 
> > > NFS is by far simpler to use in pure Linux environment, Samba is for
> > > Windows networks. NFS has no passwords, just install it with apt-get,
> > > and declare /etc/exports in the server, and mount the shares in the
> > > clients /etc/fstab. That's all it takes.
> > > 
> > > NFS offers native looking folders to *nix machines over networks.
> > > <snip>
> > > I don't know a lot about either but is "no passwords" still true
> > > with NFS4? Even if it is, is that one of the security issues the
> > > original poster is concerned about?
> > > 
> > > Under heavy concurrent usage, are there locking issues with either?
> > > Which performs better under heavy load with lots of random file IO?
> > > I am particularly interested because our environment has been build
> > > around iSCSI.  There is a possible shift in a core technology for us
> > > which may shift us from a SAN using iSCSI to a NAS using either NFS
> > > or SMB so we, too, are quite interested in others' experiences.
> > > Thanks - John
> > 
> > SANs will almost always perform better than NAS', FWIW. 
> > 
> > NFS has the better load handling and has good locking (provided you
> > run it as recommended with portmap, statd, etc.)
> > Samba is primarily used to share files to windows hosts.
> > 
> > The security architecture of NFSv3 and earlier is based on simple UID
> > reliance. You can stop root access altogether, and there's little
> > concern of NFS leading to a system being corrupted, but it IS
> > technically possible for a malicious user to delete other users files
> > if you have write allowed. NFS is usually used in environments with
> > trusted users (i.e. share only to specific machines, not the world). 
> 
> just to mention it:
> 
> NFSv3 has real security concerns (you have to trust in all machines
> connected to the network. A LOCAL root account on a client is sufficient
> to gain access to all files in the NFS-directory (by faking the UID). 
> 
> For NFSv4 this has changed. You can use NFSv4 in different modes. The
> easy one has the same problem.
> However, you can switch on strong authentification (based on Kerberos),
> then it's safe (the server verifies that the client has the correct
> Kerberos-token of this user -- UID is not sufficient), and even ask to
> sign all transfers (to block man-in-the-middle-attacks which could
> change the commands sent to the server) and encryption (to protect data
> privacy).
> 
> However, it's much more work to install, as you also need a full
> Kerberos-setup....

As I said, NFSv3 is for trusted environments. Many thousands use it with success and security, you simply consider the security problem carefully before implementation. Anyone you grant access to a share may, if malicious, read or write everything (if write is enabled) in that share. Limiting the scope of shares is usually sufficient even for corporate security requirements such as SOX and HIPAA. 

-- 
Liam

Attachment: signature.asc
Description: Digital signature


Reply to: