[afnog] Problem mounting a NAS device - FreeBSD
Ghislain Nkeramugaba
ghislain.nkeramugaba at gmail.com
Fri May 11 08:01:47 UTC 2007
Thanks Geert for the explanations.
I removed the "-o" options and tried it out again; I was able to mount it
correctly.
The device supports RPC, hence to be "NFS" capable.
Thank you again.
On 5/11/07, Geert Jan de Groot <GeertJan.deGroot at xs4all.nl> wrote:
>
> On Thu, 10 May 2007 17:50:52 +0200 "Ghislain Nkeramugaba" wrote:
> > I am running FreeBSD 5.3 and would like to attach a NAS device.
> > The command is:
> > mount -t nfs -o username=xyz,password=abc A.B.C.D:/folder/subfolder
> > /local/folder
> > I am getting an error :nfs: -o username=: option not supported
> > How come it says not supported yet the man pages refer to the "-o"
> options?
> > I am trying this on the command line, if it mounts it, i will edit the
> > /etc/fstab file
>
> I don't see '-o username=xyz,password=abc' mentioned in the
> manual pages, archived on FreeBSD.org (I don't have a box to play with),
> and frankly, I don't think what you want, can work.
>
> NFS doesn't work like some of the other filesystems. It is a
> kernel-mode to kernel-mode communication channel with a few limited
> primitives, like open-file, read-block and write-block.
> The context of usernames and passwords doesn't exist.
> The only thing communicated is the numerical UNIX user ID -
> the password files are best left in sync on both server and client!
>
> Protection is typically only based on a. the ability to speak the
> NFS protocol at all, and b. the ability to get a root NFS handle.
> It's only the 2nd part that has any userland interaction.
> Past that stage, there is no, repeat none, protection/mapping
> of any kind.
>
> First, are you sure the NAS box speaks NFS? These boxes typically
> run pinguin inside, and have userland utilities that play chroot-like
> games, username mapping and the like. This doesn't go well with a
> low-level protocol like NFS, so the ones I am familiar with (Lacie),
> don't even speak NFS.
>
> I would use rpcinfo to check whether there is any RPC support on
> your NAS box. If it isn't, then attempting an NFS mount is futile.
> If it does support RPC, then it's just host (ip-address) based
> security, and that's it. Note that none of this speaks about
> usernames/passwords; the NFS mount protocol doesn't know what
> to do with them.
>
> If the NAS box does indeed speak NFS, and on my (NetBSD) box
> it looks like this:
> $ rpcinfo
> program version netid address service owner
> 100000 4 tcp 0.0.0.0.0.111 portmapper superuser
> 100000 3 tcp 0.0.0.0.0.111 portmapper superuser
> 100000 2 tcp 0.0.0.0.0.111 portmapper superuser
> 100000 4 udp 0.0.0.0.0.111 portmapper superuser
> 100000 3 udp 0.0.0.0.0.111 portmapper superuser
> 100000 2 udp 0.0.0.0.0.111 portmapper superuser
> ...
> 100005 1 udp 0.0.0.0.3.248 mountd superuser
> 100005 3 udp 0.0.0.0.3.248 mountd superuser
> 100005 1 tcp 0.0.0.0.3.253 mountd superuser
> 100005 3 tcp 0.0.0.0.3.253 mountd superuser
> ...
> 100003 2 udp 0.0.0.0.8.1 nfs superuser
> 100003 3 udp 0.0.0.0.8.1 nfs superuser
> 100003 2 tcp 0.0.0.0.8.1 nfs superuser
> 100003 3 tcp 0.0.0.0.8.1 nfs superuser
> (note that 8*256 + 1 = 2049, which is the NFS port)
>
> The next thing is to make sure that mountd on the NAS box gives
> your FreeBSD an NFS handle. This is controlled via /etc/exports,
> (or probably a GUI interface on the NAS box that essentially does same),
> and is the *only* security the protocol has.
>
> If mountd hands out an NFS handle, the client uses it to "mount"
> the server and things should work.
>
> Lastly, note that NFS has a very, very weak protection model and
> is only usable if you have full control over server and client.
> You *must* filter TCP/UDP port 111, and TCP/UDP port 2049 for
> anything outside your own administration.
> None of these protocols have any business on the Internet-at-large,
> they are intended for office environments where there is full control
> over the machines involved. You are playing with fire.
>
> This is long and you probably lost interest. That's fine,
> but please re-read the previous paragraph about NFS security.
>
> Cheers,
>
> Geert Jan
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://afnog.org/pipermail/afnog/attachments/20070511/d268ab44/attachment.html
More information about the afnog
mailing list