-
Notifications
You must be signed in to change notification settings - Fork 32
I'm not actually sure if this is an gssproxy issue or related to something else...
I have the following entries in /etc/idmapd.conf on the server:
....
[Translation]
Method = static,nsswitch
[Static]
backup/lisa.my-home.de@MY-HOME.DE = borg
backup/mona.my-home.de@MY-HOME.DE = borg
....
Intention is that the principal ,which is used in a keytab does authenticate on the server and has access rights of user borg and id is mapped for file an directory onwership. This is actually working when no gssproxy is installed on the the server. But if it is installed all files owned by user "borg" on the server are display as owned by "nobody" on the client and file access is not granted If I than remove the static mapping entry, than the correct ownership is displayed, but access to the file is of course not permitted (which is correct in this case as user backup is not allowed to access borg's files...).
Than again authentication and user mapping with a keytab for "borg@MY-HOME.DE" (without the host name part) does work with correct mapping and access rights even in gssproxy, but than I would have to use the same keytab on different clients, which is not the intention...
So I think the static mapping should only be used for authentication to the nfs4 server, but for ownership should still the original user be used and displayed. At least it is working this way without gssproxy.
All reactions
-
👀 1
Access control is operated on the nfs server, which needs to be able to map the incoming principals to a user.
When using gssproxy on the server this is done via the getlocalname() interface and idmap.conf is completely ignored (because libidmap is not thread safe and implements many things incorrectly, so I decided not to add support for it). Additionally idmap was always superfluous because kerberos already has a mapping mechanism, and I chose to be consistent system-wide rather than cater for different overrides just for nfs (which can still be done by giving a dedicated krb5.conf file to the nfs server anyway).
You can map principals to local users in krb5.conf if you have special rul...
Replies: 3 comments 4 replies
OK, I think I understand now what I need to do ...
I should use
....
[Translation]
Method = nsswitch
GSS-Methods = static,nsswitch
[Static]
backup/lisa.my-home.de@MY-HOME.DE = borg
backup/mona.my-home.de@MY-HOME.DE = borg
....
in order to get the behavior I want.
All reactions
The answer above looks correct to me, but it is still not working.
The result now is that ownership is displayed correct, but file access for user borg, authenticated with storebackup/lisa.my-home.de@MW-HOME.DE, is not granted.
All reactions
Access control is operated on the nfs server, which needs to be able to map the incoming principals to a user.
When using gssproxy on the server this is done via the getlocalname() interface and idmap.conf is completely ignored (because libidmap is not thread safe and implements many things incorrectly, so I decided not to add support for it). Additionally idmap was always superfluous because kerberos already has a mapping mechanism, and I chose to be consistent system-wide rather than cater for different overrides just for nfs (which can still be done by giving a dedicated krb5.conf file to the nfs server anyway).
You can map principals to local users in krb5.conf if you have special rules, see the auth_to_local option in krb5.conf(5)
All reactions
-
👍 1
OK, thanks this helps. May be you could add something saying this to the docs....
All reactions
I would accept a patch to the NFS.md doc if you have a clear idea of what to write, or even just an issue that describes precisely the kind of change you'd think would make this clearer in the doc.
All reactions
All reactions
Take a look at #102 if you can.