Bob Latham <
bob@sick-of-spam.invalid> wrote:
To be honest, that sounds exactly like LM98 to me. Nothing in normal
Sunfish use appears to be a drag-able file to me. However, I have
found a file that describes my NAS connection at:
SDFS::Minim.$.!Boot.Choices.Sunfish.mountsave.red/volume1/music
That's the one.
It contains this...
Protocol: NFS3
Server: RED
Export: /volume1/music
uid: 0
gid: 0
gids:
umask: 022
Transport: TCP
ShowHidden: 1
FollowSymlinks: 5
CaseSensitive: 1
UnixEx: 0
TranslateWin: 1
DefaultFiletype: FFF
AddExt: 1
unumask: 600
MaxDataBuffer: 0
Pipelining: 0
Timeout: 20
Logging: 0
It may use other wording but nothing about "no conversion".
Is it perhaps the 'TranslateWin: 1'?
I wish I understood uid, gid and gids but I don't, the more I read
about them the more confused I become. I realise I'm probably wrong
but this security system seems to be a confused, complex, dog's
breakfast to me compared to a username and password expected
everywhere else.
Let me try...
The thing to understand about NFS is that it's designed for a business
network where every machine is run by the same people. Security is governed
by who is able to connect to the network, not by passwords. Think back to
the 1980s when all we had was wired ethernet and laptops weren't a thing and you get the idea. This mode of NFS is now called sec=sys.
So what you had was a big server in the basement and a number of clients
(Unix workstations typically) networked to it. One administrator controlled them all - that meant that administrator 'root' on the server was 'root' on
the workstations, and individual user accounts on the server were mirrored
by user accounts on the clients.
Unix has the idea of 'user id' and 'group id' which are numbers - there's
files (/etc/passwd and /etc/group) which translate them to names for
niceness, but fundamentally they're numbers. eg I might be user 1002 and
that user is in groups 34, 67, 88 and 915 - these numbers are the user id
'uid' and group ids 'gid' respectively. Every file is owned by a user and a group, ie I can access files owned by user 1002 or is owned by one of the groups that I'm in (and gives me user read/write or group read/write permissions).
When you connect to a original NFS server your machine said 'hey, I'm user
1002 and today I'm group 34' (my uid=1002 and gid=34) and the server would
say, ok here's the filesystem, you can only read and write the files that
user 1002 and group 34 have access to. Note no authentication whatsoever,
but that's ok because I'm logged into my workstation as user 1002 and the administrator doesn't give me rights to change that. So I login to my workstation with a local password, I can see the files on the server but I
only have access to files that user 1002 and its groups have access to. All
is fine.
In case you don't want everyone to access your server you can limit them
based on IP addresses - eg only the IP address range 192.168.44.0/24 is
allowed to access the server, or IP 192.168.44.7 is only allowed to access
this part of the server as that user. On Unix/Linux these settings are in
an 'exports' file which is typically found at /etc/exports. Again this
works because access to the network is strictly controlled.
However 'PCs' aren't like this - there's no shared administrator that
controls every PC and makes sure that they only say 'hey, I'm user 1002' and not 'hey, I'm user 1004' and get access to someone else's files. So in the late 80s a thing called PC-NFS came along which used usernames and passwords instead of just asserting what uid/gid you are. Unfortunately this didn't catch on (but there are still some traces lying around to trip people up).
That was the state up until NFSv3.
When NFSv4 along came Kerberos (or 'sec=krb5'), which uses cryptographic 'tickets' as a way of proving your identity. You authenticate with an authentication server (password, key, fingerprint, whatever) and you get a ticket. You hand the ticket over to the NFS server which allows you access
to the files.
v4 has this solid user-based security but unfortunately Sunfish doesn't implement it, it's stuck on v3. So that means you have to fall back on the original setup where you restrict access based on IP addresses only.
So what of the uid/gid settings in Sunfish? This is what to send to the
server 'which user should I pretend to be'. uid=0/gid=0 is the
administrator 'root' which means 'access any files' (although there is a setting root_squash on the server which can block root access). If you had
a user on the server, by setting these to the uid and gid of that user you could access the files as if you're that user.
But fundamentally there is no security in NFSv3 because a rogue client could just claim to be whatever uid/gid they want to be. The only protection is
to lock things down at the network level - don't allow things you don't
trust access to the network. That's how things have to be with NFSv3.
An NFSv4 version of Sunfish would be a fine thing, but it's a fair bit more complex than v3 and seems nobody has tackled it.
Theo
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)