[38596] in Kerberos
Re: Correct way to provide access to kerberised NFS services to
daemon@ATHENA.MIT.EDU (Charles Hedrick)
Fri Aug 9 13:56:30 2019
From: Charles Hedrick <hedrick@rutgers.edu>
To: Laura Smith <n5d9xq3ti233xiyif2vp@protonmail.ch>
Date: Fri, 9 Aug 2019 17:56:07 +0000
Message-ID: <0908C5ED-9742-4517-AAD0-82F9E230A865@rutgers.edu>
In-Reply-To: <LU-eYlThtPp6at9HaEVmZl3bs_GtudYA6pYrENFhpnFVnUk6wsyT4rbXuTya7gROVmW8-jw4vZBCwQwjTxv5TNu1eMv69ZvHgSa1YGUuu0U=@protonmail.ch>
Content-Language: en-US
Content-ID: <3123984380A7CE43913FF97C6C007643@namprd14.prod.outlook.com>
MIME-Version: 1.0
Cc: "kerberos@mit.edu" <kerberos@mit.edu>
Content-Type: text/plain; charset="utf-8"
Errors-To: kerberos-bounces@mit.edu
Content-Transfer-Encoding: 8bit
Typically you create a key table. Most installations have one for root, /etc/krb5.keytab. But you can create one for any user. Depending upon how your kerberos is set up, you’d typically use kadmin to create the key table.
At that point you can do "kinit -k -t KEYTABLE” to get a ticket. But if there’s any chance the service is going to run longer than the credential lifetime (I.e. you need credentials to be renews), you’d normally run the program under k5start. It will get a ticket, run the service, and renew the ticket when necessary.
However assuming your system runs gssproxy, and the service uses gssapi, you can have gssproxy get the ticket for you. The configuration file points to the key table, so in the end it does the same thing, just more elegantly.
> On Aug 2, 2019, at 6:24 PM, Laura Smith <n5d9xq3ti233xiyif2vp@protonmail.ch> wrote:
>
> I have a NFS share which I am mounting on as follows in the fstab:
>
> foo.example.com:/srv/share/foo /mnt/foo nfs4 defaults,sec=krb5p,noexec,nosuid,_netdev,auto 0 0
>
>
> On the server, exports reads as follows:
> /srv/share/backups/foo foo.example.com(rw,sync,sec=krb5p,all_squash,subtree_check,anonuid=473,anongid=474)
>
>
> The NFS share mounts perfectly on the client.
> Root can read/write/delete from the share perfectly.
>
> But a "standard" user can't do anything, e.g.
>
>
> /mnt$ ls
> ls: cannot access 'foo': Permission denied
>
>
> The purpose of this share is to, for example, allow system services running as lesser users to save files. Therefore non-root access is key.
>
> So what is the correct way to allow system/daemon service users to get a kerberos ticket to gain access to the NFS share (which I assume is the underlying problem here ?)
>
> Obviously a daemon cannot be expected to do a normal kerberos login.
>
> Or are there better ways to mount a NFS share at system level for all users to acccess ?
>
> I'm guessing more than one person here has come across the problem.
>
> ________________________________________________
> Kerberos mailing list Kerberos@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
