yeah, same here…i"m going to give up 
@Chewi any chance to get guidances and you try to reproduce step by step what you did…I surely miss something. For the coding I know what to do 
1 Like
Yes, but after you manage the file permission by UID/GID. I’m now looking in this direction.
Back to my first idea…get ride of kerberos
NFS is IP based, but it uses the unix GID/UID, it means that if you are not in the correct GID (group) you cannot read/write/remove folders/files. It is the current behaviour actually.
Event if you mount the nfs share, I cannot browse it (except by root) because I’m not in the default group (domain users@domain.com for example). nfs respects the linux permissions.
from here I have two solutions
- Share the same gid between the server and the client (add a new group to the user’s client). it will add a new level of authentication
- Say to nfs to squash the gid/uid of the client and recreate it following the default user/group of the IBAY. All files/folders created will own this group/user permissions.
This how I want to declare my export
/var/lib/nethserver/ibay/plop/ *(rw,all_squash,sync,anonuid=335600500,anongid=335600513)
anonuid=335600500 -> uid of administrator
anongid=335600513 -> gid of domain users@domain.com
Of course you have just an IP based access…all clients will be able to read/write if the export allows it (from its IP). But it drives something simple, less modifications from each side, you don’t have to change or trick acl on NS…if needed, only the client part must be modified.
Therefore we can have two modes
paranoid -> Gid/uid must be set on the clients and the IP based access must be respected
lazzy -> Only the IP access will be used to allow write/read permissions
I like this one: KISS approach.
I like this too.
@stephdl
Cool, thanks!
I’m looking forward.
We have according to the weather a fantastic weather - sun …
I think it is reasonable as a first prototype.
Next steps could be:
- IP access policy for SMB too: is it possible? It would be good for LDAP accounts provider!
- kerberos auth for NFS too!
It would be great to have the same features on both protocols!
I don’t know about others, but for me NFS (Network File System) is more to interconnect servers such as iSCSI;
Personally on Nethserver; I’ll use it to mount a drive inside a KVM such as CoreOS to store my datas
So authentication based on IP works very well for this kind of usage.
4 Likes
Correction, it is a snowy day
I’m thinking loudly, please add your mind
When I did a contrib for SME Server, I added a lot of protections mostly IP based, it means
you cannot get a RW export if the ip is not on the LAN
you cannot get a RW export if the export is for the whole LAN (each IP with RW right must be set)
I created also the possibility to create your own rule manually when the option in the panel are not enough, but I forbid
- ‘*’ since it means accept from everywhere
- domain name (so easy to spoof)
- no space between IP and option (it means accept from everywhere)
Do you want the same, or it is useless
great!
cool!
Check box or radio button…the first one could give the interface lighter :-?
IMO delay, hide, secure, each with a single checkbox. Maybe also RW.
1 Like
I’d prefer one interface to rule them all!
I mean: NFS and SMB features are similar. IP-based access policy could be added to smb.conf with an hosts allow = ... directive.
And authentication can be added to NFS (ok, in a second step). We’ll get the same features on both protocols!
If we move towards this goal we can design one interface for both protocols and ease the configuration.
Also at DB level the props could be the same!
What do you think?
Agreed, but I have two minds on it, we need to assume that we might have two different policies because we have two different protocols.
Why not But I would prefer a panel for each protocol.
Authentication with kerberos, why not, the only change (quite near) is the export definition, so we can imagine several way to use nfs
- IP based and UID/GID
- IP based
- Kerberos
It is really flexible 
This is a great Idea you gave me, reuse some db…I was thinking to another tricky way.At least ‘GroupAccess’ could be used instead of NfsRW. However other db are specific…hard to reuse it.
My workarea is at GitHub - stephdl/nethserver-nfs of course it is not polished
A distinct panel could be required for those features that are provided by a specific protocol only.
For instance, sync/async is an NFS-only option. It does not apply to SMB (and we could discuss if it is worth exposing it on the UI…).
The list of IP addresses that are allowed to connect the shared folder should be the same for both protocols. I mean: if the sysadmin requested an IP-based access policy I think it is correct to enforce it on any possible protocol.
What do you think?
Agreed
I tend to think the contrary, and I want to hide them by an ‘advanced setting’ menu
I get your point, now let’s talk of the difficulty to code it
My worry is the need to get Two panels for NFS. NFS is IP based, I don’t allow to share something in RW easily, You have to write all allowed IP in the textbox area, then if needed you can allow them in RW mode and/or set all other options. For the 'Read mode ’ from your LAN, you have a checkbox, however the options are restricted by the UI(all_squash,ro,secure).
Then we will have two panels (one for setting, one for IP), it is less handy. After that I’m not sure a sysadmin will want obviously the IP restriction for the two protocols, but we can imagine a chekbox in samba to enable/disable it.
If an IP panel is wanted, how make it ?
- With a table from a specific key → nice, but not easy to fill (one IP by step)
- With a textarea box(simple, easy to copy and paste, a bit oldy)
For the textarea, I succeed the last night to verify the IP line directly in nethgui, I need now to verify that the range is good in the trusted network…a new (little) victory
1 Like
I’d definitely go with it! Please, have a look to an already existing implementation for “Email > SMTP access”:
About the interface design, I think we need to draw some use cases to validate it. I hope someone else wants to chime in! /cc @dev_team @quality_team.
What comes to my mind is
- Primary, historical use case: authenticated access, ro/rw perms for team collaboration, optional ro for everyone
- ro/rw guest access
- IP based + guest access: ideal for machine backups, could be useful where authenticated access is not provided (LDAP accounts provider)
This is the reason because I’d like the IP textarea in the General tab (and develop a smb.conf template for it). In the future I’d like authenticated access on NFS, too: is it possible?
About the NFS tab: I agree, it could list the “advanced options” of NFS protocol. But I’d list only options that are useful to real use cases!