-
|
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: 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...). |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 4 replies
-
|
OK, I think I understand now what I need to do ... I should use in order to get the behavior I want. |
Beta Was this translation helpful? Give feedback.
-
|
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/[email protected], is not granted. |
Beta Was this translation helpful? Give feedback.
-
|
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) |
Beta Was this translation helpful? Give feedback.
-
|
OK, thanks this helps. May be you could add something saying this to the docs.... |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
I think it would be sufficient to write that libidmap interface is not implemented and that one hat to use the krb5.conf for id-mapping requirements.
Am Freitag, 3. Mai 2024, 15:00:47 CEST schrieb Simo Sorce:
… 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.
|
Beta Was this translation helpful? Give feedback.
-
|
Take a look at #102 if you can. |
Beta Was this translation helpful? Give feedback.
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…