username/cron principals and cron
krienke at uni-koblenz.de
Wed May 6 10:04:55 EDT 2015
I think I found the answer to this problem:
Start a cronjob using a username/cron at REALM principle for a user who
has his home on NFS4/kerberos directory who wants to access his home
directory from within the cron job.
The solution has been discussed earlier here, I found the helpful hints
here in the archive:
After all the cron-principal is just handled like NFS4 root access. In
this case the client sends nfs/machine.domain at REALM as principal to the
NFS server which can be rewritten to root in /etc/idmapd.conf by adding
a line like
nfs/machine.domain at REALM = root # allow NFS root access
in the static section. For the cron-principal things are very similar.
The principal visible at the NFS server for idmapping is simply
username/cron at REALM and can be rewritten to eg username so that a
cronjob authenticated with the help of this cron principal can also
write to NFS4 filesystems as unix user "username". So in this case you
add a line to /etc/idmapd.conf's static section like:
username/cron at REALM = username
I think you only have to do this on the NFS4 server. At the moment I
have this mapping on both NFS server and client but I guess configuring
it on the server should be sufficient.
Am 06.05.2015 um 10:10 schrieb Rainer Krienke:
> Hello to everyone,
> thank you Rank and thank you Robert for your answers. I tried to find
> out more. Beeing root on a NFS4 client I ran the following commands with
> different results. Before I tried this I commented out my auth_to_local
> rules from /etc/krb5.conf:
> # su username -c "/usr/bin/kinit username/cron at MYREALM; touch
> Password for username/cron at MYREALM: ******
> touch: cannot touch `/home/username/xx': Permission denied
> and after a reboot of the NFS client and after kdestroying all the
> /tmp/krb5_* caches I ran this:
> # su username -c "/usr/bin/kinit username at MYREALM; touch /home/username/xx"
> Password for username at MYREALM: ******
> # <success: no error message>
> So using principal username/cron at MYREALM does not permit the unix user
> username to write to NFS while principal username at MYREALM does.
> Behind the scene there is an ldap server that NFS client and server are
> configured to use in order to find out eg the uid of user "username" for
> id mapping. Running a getent passwd username returns on both sides the
> same entry with the same unix uid and gid.
> So the question for me is, should a principal "username/cron" be
> automaticall be mapped to a local unix user "username" so that
> "username" is then allowd to access a NFS4 mounted directory that
> belongs to "username". This is what does not work for me at the moment.
> Does anyone have such a setup thats working? Is perhaps some kind of
> flag needed for the kerberos cron-principal to make it work?
> If I try to play around with auth_to_local rules, that to my
> understading are thought for this purpose, where do I have to defined
> them? On the NFS client, the NFS Server or the Kerberos Server or on all
> of them?
> Thanks a lot
> Am 05.05.2015 um 16:43 schrieb Frank Cusack:
>> I'm surprised you need a mapping at all. The default mapping should
>> simply strip any instance component. What happens if you kinit
>> "manually" with username/cron using a password?
>> On Tue, May 5, 2015 at 4:24 AM, Rainer Krienke <krienke at uni-koblenz.de
>> <mailto:krienke at uni-koblenz.de>> wrote:
>> I am setting up a kerberos/NFS4 environment. Basically everything seems
>> to work. Every user has of course a princiapl username at MYREALM, where
>> username is the unix user name. The users homes are on a kerberos/NFS4
>> mounted directory.
> Kerberos mailing list Kerberos at mit.edu
Rainer Krienke, Uni Koblenz, Rechenzentrum, A22, Universitaetsstrasse 1
56070 Koblenz, http://userpages.uni-koblenz.de/~krienke, Tel: +49261287 1312
PGP: http://userpages.uni-koblenz.de/~krienke/mypgp.html,Fax: +49261287
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 5065 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.mit.edu/pipermail/kerberos/attachments/20150506/10df1395/attachment-0001.bin
More information about the Kerberos