8:02 a.m.
Hello everyone!
I am trying to setup an NFS export with sec=krb5p on one machine and
make it accessible to a system user ('git' in this case) on another. I'd
like to put GitLab backups on my ZFS array via NFS, to be more specific.
All machines in my little homelab are based on CentOS 7.3.1611 and I use
two replicated FreeIPA servers with what I believe to be the latest
release available on CentOS: 4.4.0. Both the storage server and the
GitLab server are enrolled hosts in my realm.
After enrolling both machines with ipa-client-install and installing
@File\ and\ Storage\ Server on one and @Network\ File\ System\ Client on
the other, I ran ipa-client-automount on both, as I read somewhere that
it sets up neccessary configuration files for identity mapping?
I also found a thread on this mailinglist, about a usecase of Apache
accessing a /var/www directory via kerberized NFS. I believe my usecase
is very similar and I feel like I am very close to a solution. But I
just don't understand where things go wrong:
In this particular case the 'git' user on both machines has different
UIDs. It was created during the installation of GitLab on the client but
the UID was already occupied by 'softhsm private keys owner' on the
server. Thus I created a system user manually, which has a different UID
though. For the sake of troubleshooting I also tried all the following
steps with the Apache user, which has UID 48 on both machines - the
result was the same.
As this is not an actual user in my realm, I first created a service
principal of the form git/$HOSTNAME@REALM (or apache/... for that
matter). I then used ipa-getkeytab to create a keytab in
/var/lib/gssproxy/clients/$UID.keytab for gssproxy to find. That worked
nicely as in: The user automagically got access to the mounted NFS share
while a krb5cc_$UID was created in the directory mentioned above. After
switching users with su, I can navigate through the mount - as long as
all the folders have 755 permissions. A folder with 700 permissions and
owner 'git' is correctly displayed as being owned by 'git' on the client
- yet I cannot access it! When I create a file or folder in a folder
with public permissions (777), the owner of the newly created file is
'nfsnobody'.
I also tried setting up a static mapping in /etc/idmapd.conf on both the
server and client: mapping the service principal to user 'git'. The
effect was the client displaying the folder being owned by 'nobody' -
whoops.
Doing all the above steps with an actual user in the realm works fine.
Either with the automagic method through gssproxy or by getting a ticket
with kinit first: I can access a folder with 700 permissions and files
are created with the correct owner, etc.
Is there any critical step that I missed? I feel like I am very close ..
I'd be thankful for any hints.
Cheers,
Anton
2:03 p.m.
Did you also set the Method in idmap.conf to include static?
On Jul 17, 2017, at 9:02 AM, Anton Semjonov via FreeIPA-users
<freeipa-users@lists.fedorahosted.org<mailto:freeipa-users@lists.fedorahosted.org>>
wrote:
I also tried setting up a static mapping in /etc/idmapd.conf on both the
server and client: mapping the service principal to user 'git'. The
effect was the client displaying the folder being owned by 'nobody' -
whoops.
3:19 p.m.
Yes, I did. Basically:
```
[Translation]
Method = static,nsswitch
[Static]
git/$HOSTNAME@$REALM = git
```
.. With the rest of the file left untouched and I used the actual
hostname and realm, of course.
On 18/07/17 21:03, Charles Hedrick via FreeIPA-users wrote:
> Did you also set the Method in idmap.conf to include static?
>
>> On Jul 17, 2017, at 9:02 AM, Anton Semjonov via FreeIPA-users
>> <freeipa-users(a)lists.fedorahosted.org
>> <mailto:freeipa-users@lists.fedorahosted.org>> wrote:
>>
>> I also tried setting up a static mapping in /etc/idmapd.conf on both the
>> server and client: mapping the service principal to user 'git'. The
>> effect was the client displaying the folder being owned by 'nobody' -
>> whoops.
>
>
>
> _______________________________________________
> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
>
3:11 p.m.
Hello again.
As a follow-up, I tried some further troubleshooting on two fresh
virtual machines. The setup process was as follows:
[both]
- install CentOS via kickstart
- change hostname
- ipa-client-install
- ipa-client-automount
- install @Network File System Client / @File and Storage Server
- useradd --system --no-create-home git
- add static mapping in /etc/idmapd.conf (see other reply)
- add service principals in ipa:
* git/test00.client.$domain@$REALM
* nfs/zfs0.storage.$domain@$REALM
[server zfs0.storage.$domain]
- kinit -k
- ipa-getkeytab -p nfs/$HOSTNAME -k /etc/krb5.keytab
- create a directory structure for exporting:
• root @zfs0 ~ # ls -la /media/testenv/
total 0
drwxr-sr-x. 1 admin kerberos 18 Jul 19 20:56 .
drwxr-xr-x. 1 root root 14 Jul 19 00:06 ..
drwx--S---. 1 git kerberos 0 Jul 19 00:06 git
drwxrwsrwx. 1 root kerberos 8 Jul 19 19:02 public
- export with '/media *(rw,sec=krb5p,crossmnt,fsid=0,sync)'
- add firewalld service nfs permanently
- reboot
[client test00.client.$domain]
- kinit -k
- ipa-getkeytab -p git/$HOSTNAME -k /var/lib/gssproxy/clients/$(id -u
git).keytab
- fstab: zfs0.storage.$domain:/ /media nfs4 defaults,proto=tcp 0 0
- reboot
Then, logging in to the client and switching users with 'su - git'
allowed me to navigate in /media, yet again I was denied access to the
folder owned by git:
• git @test00 /media/testenv $ ls git
ls: cannot open directory git: Permission denied
Gssproxy surely seems to use the client keytab, a cache is created:
• root @test00 / # klist -kt /var/lib/gssproxy/clients/995.keytab
Keytab name: FILE:/var/lib/gssproxy/clients/995.keytab
KVNO Timestamp Principal
---- -----------------
--------------------------------------------------------
1 18/07/17 23:32:43 git/test00.client.$domain@$REALM
1 18/07/17 23:32:43 git/test00.client.$domain@$REALM
• root @test00 / # ll /var/lib/gssproxy/clients/
total 8
-rw-------. 1 root root 198 Jul 18 23:32 995.keytab
-rw-------. 1 root root 1815 Jul 19 19:02 krb5cc_995
After adding some verbosity flags ("-vvv" in /etc/sysconfig/nfs and
"Verbosity = 5" in /etc/idmapd.conf) I recorded logs while I was
(re)mounting the nfs share and navigating through folders. The static
idmap mapping seems to work:
59: nfsidmap[9406]: key: 0x1802b55 type: uid value:
git/test00.client.$domain@$REALM timeout 600
60: nfsidmap[9406]: nfs4_name_to_uid: calling static->name_to_uid
61: nfsidmap[9406]: static_getpwnam: name
'git/test00.client.$domain@$REALM' mapped to 'git'
62: nfsidmap[9406]: nfs4_name_to_uid: static->name_to_uid returned 0
63: nfsidmap[9406]: nfs4_name_to_uid: final return value is 0
.. but as stated above I am still denied access. The logs are attached,
because otherwise Thunderbird rips the formatting apart. I hope that
this clarifies my situation a little and allows for some reproduceability.
Where could I further increase verbosity to see what principal/username
is actually transmitted to the NFS server when I am denied access? Is
there a NFS4 specific mailinglist where I could ask?
Greetings from Germany,
Anton
On 17/07/17 15:02, Anton Semjonov via FreeIPA-users wrote:
Hello everyone!
I am trying to setup an NFS export with sec=krb5p on one machine and
make it accessible to a system user ('git' in this case) on another. I'd
like to put GitLab backups on my ZFS array via NFS, to be more specific.
All machines in my little homelab are based on CentOS 7.3.1611 and I use
two replicated FreeIPA servers with what I believe to be the latest
release available on CentOS: 4.4.0. Both the storage server and the
GitLab server are enrolled hosts in my realm.
After enrolling both machines with ipa-client-install and installing
@File\ and\ Storage\ Server on one and @Network\ File\ System\ Client on
the other, I ran ipa-client-automount on both, as I read somewhere that
it sets up neccessary configuration files for identity mapping?
I also found a thread on this mailinglist, about a usecase of Apache
accessing a /var/www directory via kerberized NFS. I believe my usecase
is very similar and I feel like I am very close to a solution. But I
just don't understand where things go wrong:
In this particular case the 'git' user on both machines has different
UIDs. It was created during the installation of GitLab on the client but
the UID was already occupied by 'softhsm private keys owner' on the
server. Thus I created a system user manually, which has a different UID
though. For the sake of troubleshooting I also tried all the following
steps with the Apache user, which has UID 48 on both machines - the
result was the same.
As this is not an actual user in my realm, I first created a service
principal of the form git/$HOSTNAME@REALM (or apache/... for that
matter). I then used ipa-getkeytab to create a keytab in
/var/lib/gssproxy/clients/$UID.keytab for gssproxy to find. That worked
nicely as in: The user automagically got access to the mounted NFS share
while a krb5cc_$UID was created in the directory mentioned above. After
switching users with su, I can navigate through the mount - as long as
all the folders have 755 permissions. A folder with 700 permissions and
owner 'git' is correctly displayed as being owned by 'git' on the client
- yet I cannot access it! When I create a file or folder in a folder
with public permissions (777), the owner of the newly created file is
'nfsnobody'.
I also tried setting up a static mapping in /etc/idmapd.conf on both the
server and client: mapping the service principal to user 'git'. The
effect was the client displaying the folder being owned by 'nobody' -
whoops.
Doing all the above steps with an actual user in the realm works fine.
Either with the automagic method through gssproxy or by getting a ticket
with kinit first: I can access a folder with 700 permissions and files
are created with the correct owner, etc.
Is there any critical step that I missed? I feel like I am very close ..
I'd be thankful for any hints.
Cheers,
Anton
_______________________________________________
FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
2471
days inactive
2473
days old
freeipa-users@lists.fedorahosted.org
3 comments
2 participants
participants (2)
-
Anton Semjonov -
Charles Hedrick