[Samba] nfs root kerberos

[Jason Keltz]

On 11/12/2020 10:05 AM, Rowland penny via samba wrote:
> On 12/11/2020 14:19, Jason Keltz via samba wrote:
>>
>> On 11/12/2020 8:52 AM, Rowland penny via samba wrote:
>>> On 12/11/2020 13:27, Jason Keltz via samba wrote:
>>>>
>>>> On 11/12/2020 8:17 AM, Rowland penny via samba wrote:
>>>>> On 11/11/2020 10:54, Jason Keltz via samba wrote:
>>>>>> Hi Louis,
>>>>>> I've looked into that and I'm not sure how this would be done?
>>>>>> By the way, even with your NFS translation fix (which doesn't 
>>>>>> work for me because gssproxy), do you do this before accessing 
>>>>>> root files..?
>>>>>> sudo root
>>>>>> kinit -k 'host$'
>>>>>>
>>>>> OK, after a bit of a battle, I now have a Centos 7 Unix domain 
>>>>> member mounting an NFS share from a Devuan NFS4 server.
>>>>>
>>>>> The actual mount wasn't a problem, it was getting the NFS server 
>>>>> to work 😮
>>>>>
>>>>> I used Samba AD DC's for the authentication, a Unix domain member 
>>>>> as the NFS server and a Centos 7 Unix domain member as the NFS 
>>>>> client. I did minimal setup on the Centos machine. 
>>>>
>>>> Hi Rowland,
>>>>
>>>> The problem wasn't getting NFS to work - it was getting NFS "root" 
>>>> access to work between a CentOS 7 client and CentOS 7 server  (AKA 
>>>> no_root_squash in /etc/exports).
>>>>
>>>> Finally, after a significant amount of effort, I figured that out 
>>>> last night.
>>>>
>>>> In my case, I needed to add a realms section for realm 
>>>> AD.EECS.YORKU.CA and include 2 auth_to_local rules as follows:
>>>>
>>>> [realms]
>>>>   AD.EECS.YORKU.CA = {
>>>>     auth_to_local = RULE:[1:$1@$0](J1\$@AD.EECS.YORKU.CA)s/.*/root/
>>>>     auth_to_local = DEFAULT
>>>>   }
>>>>
>>>> This allows root on "J1" to "really" be root.  Additional of the 
>>>> first line are required for each system.  The DEFAULT line is 
>>>> required.   Lots of fun let me tell ya.
>>>>
>>>> Jason.
>>>>
>>>>
>>> Define what you mean by 'really root' ?
>>>
>>> The root user is a Unix user and, as such, has nothing to do with AD 
>>> (or NFS).
>>>
>>> If you can login into a Unix domain member, you should be able to 
>>> use root and if you login into a Windows domain member, then try to 
>>> use root, it should go 'root ? who is that ?'
>>>
>>> So, when you log into a Unix domain member, what isn't working ?
>>
>> Rowland,
>>
>> In the NFS world, by default, "root" on the NFS client is actually 
>> mapped to user "nobody" or "nfsnobody" on the NFS share for 
>> security.  Try it.  Go into the NFS share, and touch a file as root. 
>>    With a sec=sys mount (no Kerberos security), you can allow root on 
>> the NFS client to access the NFS filesystem as root only if you 
>> export the share with the no_root_squash option (which is not the 
>> default).  With Kerberos, sec=krb5, etc. in order to not have root 
>> mapped to nfsnobody on the NFS share, you have to do use the 
>> no_root_squash option, PLUS the additional step that I described (at 
>> least for CentOS 7 with gssproxy). When using Debian, without 
>> gssproxy, you would use /etc/idmapd.conf in the way that Louis 
>> described for creating a translation of the root user to "root".
>>
>> Jason.
>>
>>
>>
> Well, you learn something new everyday 😂
>
> I suppose the next question is, why do you need to use root in a NFS 
> share ?
>
> I keep reading that is easier to use NFS instead of CIFS, which it may 
> be, just as long as you do not want to secure it with Kerberos. I 
> think I will stick to CIFS 😁
>
I try to learn something new every day and have various grey hairs to 
show for it!

If security wasn't an issue, I'd want to have no_root_squash enabled 
everywhere.  It would mean that if I needed to update a file that was 
owned by root on the NFS server, I could just update it on my local 
workstation without needing to log into the NFS server.  Life would be 
easy.   However, then security comes in and you realize that root on any 
local client can update any file on the server.  Having say, one system 
that mounts with no_root_squash could be useful though.

I've seen cases where say, a commercial piece of software insists on 
writing to a file as root, and if that file needs to be on an NFS share, 
you don't have too many options.  In fact (and I may be wrong), I think 
even Apache httpd wants to write the log files as root.  That means that 
if I want those web server log files NFS shared between a whole slew of 
clients, then that share has to be no_root_squash.

I don't think that securing NFS with Kerberos is all that bad at all.  
This root issue caused an additional grey hair, and initially, figuring 
it out probably caused another one, but now that I understand it, it's 
really just a few steps.  If you're comfortable with CIFS, there's no 
reason not to use that.  NFS is sure useful when you have to share the 
files between different users and groups with different permission.

Jason.