MAPALL & MAPROOT, Better Explanation Please

[House Of Cards]

Greetings,

I've read over lots of things, but I'm still a bit unclear on these functions.

If a person sets MAPROOT User and MAPROOT Group to ROOT and WHEEL respectively on an NFS share, does that essentially give the root user of a machine accessing the mounted share root access to the files stored on the FreeNAS box, and is this frowned upon from a security standpoint? This is a purely home environment with no remote access configured.

It's a little convoluted from what I've read, and I'm not clear.

Thanks!

 

[Andreas Corneliussen]

No, in fact the idea is somewhat the opposite. What setting the MAPROOT does is that it maps the root user of the machine accessing the freenas to an non-root user on the freenas box. That is, if I on my freenas setup set MAPROOT user to andcor and MAPROOT group to wheel, this means that my Desktop machine root user accesses the freenas nfs share content as were it the andcor user and wheel group on the freenas box.

 

[House Of Cards]

But in the case I described, we're mapping the MAPROOT User to user ROOT, and MAPROOT Group to group WHEEL. I don't want or see any reason to allow a day to day account on a desktop to be mapped with root privileges to the NAS box. My account is in the SUDO group locally, but backup software running with root access on the local desktop would need root access on the mounted shares to backup the NAS box shares...

Unless I'm not understanding?

 

[Andreas Corneliussen]

Ooh in that case yes mapping the root user to root and the root group to wheel will give the root user of the desktop root access to the freenas share. The MAPROOT user and group cannot be used to give root access to a normal desktop user, but the other way around, it controls what access the desktop root user has on the freenas box.

However, I can't see why your backup software on the local desktop will need root access to the NAS filesystem. Using rsync as an example it just needs to have read/write permissions depending on if the NAS system is the source or destination of the backup. Those permissions can be given to a normal NAS user and then if your backup system on the desktop needs to run under root permissions, you can map the desktop root user to the normal NAS user.

 

[House Of Cards]

I'm not sure either, but I know if I don't check the options as I've described, the backup software sees an empty mount point (i.e.; the local folder, not the mounted share or files within it)... It's CrashPlan if that helps? Support said the empty folder condition was a result of permissions on the NAS, and not local permissions. On other systems, CrashPlan ran under my user account, and could always access other files, even those I didn't have permissions for.

Not sure what's different here...

 

[Andreas Corneliussen]

As I understand NFS, it has no mapping between the desktop uid's and the NAS uid's. That is the user you are using on the Desktop machine has a specific uid and that is then used to determine which access the specific user has on the NAS. Most likely your user database on the desktop and the NAS is out of sync and therefore your desktop user has no access on the NAS at all.
There are different ways to overcome this:
* Make the NAS and Desktop authenticate against the same authentication server which makes sure that the uid's and gid's are in sync.
* Make use of the MAPALL and map all users connecting through NFS to a specific NAS user which you can then control how much access this user might need to have.

In my own setup (also a home NAS system) I am the only user accessing over NFS and I have therefore set the MAPALL to my NAS user and group and restricted the NAS shares so that only my desktop is allowed to access through NFS. I know that this might not be the most secure setup as you now have the combined vulnerabillities of my desktop and the freenas system to worry about, but it works for me and I haven't yet had the time to dabble with setting up an authentication server for my home use (I have just recently seen that freenas 9.10 actually have a domain controller service, but doesn't know what it is capable of).

 

[House Of Cards]

I have all the desktop users UID's and GID's set the same, and I'm assuming ROOT has the same UID on all UNIX machines, so they should not be different between my Linux desktop and BSD-based NAS? In fact, just looked. The UID of ROOT is 0 on both.

I've been pretty meticulous in setting up users and groups the same, and making sure they match everywhere. This could simply be a case of CrashPlan support passing the buck. After all, this isn't an officially supported use case. My only concern here is that if someone managed to hack my desktop machine and gain root access locally, they would also have root access to the NAS. Trying to prevent that.

 

[Andreas Corneliussen]

In any case they would only have root access to the NFS share. How does the share look for the normal user you would normally run the chrashplan service as? If that user can see the files then it is most certainly the chrashplan SW. I don't know the crashplan SW so I can't help you there.

 

[SweetAndLow]

I have all the desktop users UID's and GID's set the same, and I'm assuming ROOT has the same UID on all UNIX machines, so they should not be different between my Linux desktop and BSD-based NAS? In fact, just looked. The UID of ROOT is 0 on both.

I've been pretty meticulous in setting up users and groups the same, and making sure they match everywhere. This could simply be a case of CrashPlan support passing the buck. After all, this isn't an officially supported use case. My only concern here is that if someone managed to hack my desktop machine and gain root access locally, they would also have root access to the NAS. Trying to prevent that.

I highly doubt it's crashplan goofing up. I run crashplan the exact same way. I use smb mount instead of NFS but it's still the same thing.

Can your local used see all the files? Crashplan does not run at root so maproot is not the setting I think you want to mess with. You just want to make things readable by your local user.

Sent from my Nexus 5X using Tapatalk

 

[House Of Cards]

In any case they would only have root access to the NFS share. How does the share look for the normal user you would normally run the chrashplan service as? If that user can see the files then it is most certainly the chrashplan SW. I don't know the crashplan SW so I can't help you there.

My user account can see the files, add/remove files... CrashPlan saw an empty folder. Weird.

 

[SweetAndLow]

Maybe crashplan has it's own user than. If you look at the output of top it should give you the user in column 1.

Sent from my Nexus 5X using Tapatalk

 

[House Of Cards]

CrashPlan doesn't show as a command in TOP, but it is a Java application and when I force a scan in CrashPlan, there is a Java process that has a CPU spike. Assuming that is CrashPlan. That Java process is running as root.

Java running as ROOT? Scary all by itself.

 

[Andreas Corneliussen]

How are you running chrashplan? With sudo? An application doesn't get to run as root if you don't start it as root. Maybe the application can run as your normal user instead

 

[House Of Cards]

I just did the standard install as CrashPlan performs. You run the installer with sudo so it can do its thing. My assumption is that it sets up the CrashPlan service to run with root access so it can back up files that don't belong to you. I can see the directories I don't normally have access to under my user without sudo, if I browse through CrashPlan. So the app has more access than I do...

 

[Andreas Corneliussen]

In that case it should be the maproot setting you have to set. But you don't necessarily have to set it to root, setting it to another user with sufficient read priviliges on the NAS to access the NFS share files should be enough

 

[SweetAndLow]

In that case it should be the maproot setting you have to set. But you don't necessarily have to set it to root, setting it to another user with sufficient read priviliges on the NAS to access the NFS share files should be enough

I double checked and the backend crashplan service runs as root. Setting the map root to root should work or setting it to some user that can see all your files.

Sent from my Nexus 5X using Tapatalk