1

I have an NFS tree exported from a file server that is secured using Kerberos and uses LDAP for authentication and uid/gid management. Everything works swimmingly for each client machine and each individual user, but I'm not sure how to grant access to parts of the share to daemons.

The daemons typically run with a setuid to a local system account, so there aren't any specific credentials for them on the server. If I can get in and muck around with the source I can usually get them to call kinit with a keytab file for a user that exists in kerberos when they start, but this is not always possible.

Our environment prohibits me from cracking things wide open by making them world readable, or from removing Kerberos from the NFS entirely.

I fiddled with adding a subtree to /etc/exports with all_squash, anonuid=... and anongid=... set, but that just made it world-readable to every client machine. It needs to be accessible only to a certain machine.

I've tried using samba but we have some daemons that have an "NFS or bust" approach to working with shares (anything involving mercurial, for example).

Most of our servers run Ubuntu 10.04 LTS, though the problem also affects a 12.04 LTS client we have.

Is there a way I can grant an entire system a system-wide ticket for a particular Kerberos user so any user on that system can always access the share? Or is there some other method of achieving this kind of access that I can investigate?

Shabbyrobe
  • 557
  • 1
  • 7
  • 19

2 Answers2

3

A "proper" way to do this would involve rewriting init scripts to make use of k5start in daemon-mode and per-daemon keytabs. This will ensure that the running daemon has access to a valid credential cache while it is running.

You'll likely want daemon/hostname.domain.tld style principles. They're easier to track and easier to manage the keytabs for. Adding a key to a keytab automatically increments the key version number(KVNO) and randomizes the "password" for that principal.

84104
  • 12,698
  • 6
  • 43
  • 75
  • Oh thank you! This looks like *exactly* what I've been looking for. I will give it a try and report back. – Shabbyrobe Aug 15 '12 at 11:07
  • As far as the ticket refreshing goes, will the TGT last for the whole time the daemon is running or will there be a time when the daemon simply can't renew any more? – Shabbyrobe Aug 15 '12 at 11:09
  • k5start should be able to acquire a valid ticket so long as the keytab is valid and the principal can be issued tickets. – 84104 Aug 15 '12 at 14:27
1

If you are running gssproxy, with a standard nfs-client config like:

[service/nfs-client]
  mechs = krb5
  cred_store = keytab:/etc/krb5.keytab
  cred_store = ccache:FILE:/var/lib/gssproxy/clients/krb5cc_%U
  cred_store = client_keytab:/var/lib/gssproxy/clients/%U.keytab
  cred_usage = initiate
  allow_any_uid = yes
  trusted = yes
  euid = 0

You can put the service's keytab in /var/lib/gssproxy/clients/%UID%.keytab and gssproxy will handle creating the tickets for you. This can be preferable to using k5start because k5start can mess with SELinux transitions.

Orion Poplawski
  • 11
  • 3