newbie question nfs4 with kerberos

[Kevin Coffman]

On Feb 12, 2008 5:20 AM, Rüdiger Meier <sweet_f_a at gmx.de> wrote:
> Hi,
>
> On Monday 11 February 2008 17:21, Kevin Coffman wrote:
> > On Feb 11, 2008 10:08 AM, Rüdiger Meier <sweet_f_a at gmx.de> wrote:
>
> > > I can mount /home and /data as I expected but my problem now is
> > > that all file accesses by any user are "squashed" to nobody/nogroup
> >
> > That sounds more like idmapd isn't running or configured correctly?
>
> I think its working correctly, since "ls" shows me the right file
> owners.

Where are you doing the "ls"?  Without kerberos credentials, an "ls"
on the client should result in "permission denied".  It may be the
case that they do have kerberos credentials, but they are not getting
mapped to the proper uid/gid values on the server.  This would result
in a mapping to "nobody".

> > > So I guess that the users would need to get a user ticket from
> > > kerberos.
> >
> > If anyone besides root is accessing things at all, that is already
> > happening?
>
> All users have only the permissions of nobody/nogroup.
> It works correctly when I add kerberos principals for the users and get
> a ticket via "kinit".
>
> > > Is it possible to avoid that? I just want to authenticate the
> > > machines against eachother - not the users so far.
> >
> > Not that I am aware of.
>
> Hm, maybe its possible somehow to put user keys on the client
> machines like I did for these nfs macine keys?
>
> My problem is that I dont want to use expiring tickets for the users
> because they all are runninig cron jobs  and have long time vnc or
> screen sessions etc. - so I dont want to risk that their jobs suddenly
> dont have write access anymore and their jobs sould also be able to run
> even after a reboot when they never logged into kerberos.

There is no option to tell gssd to use the machine credentials for all
accesses.  You can create keytabs for individual users or daemons and
use cron, or something like kstart
(http://www.eyrie.org/~eagle/software/kstart/) to keep the users'
credential caches up-to-date.  This will still require that the
Kerberos principal be properly mapped to local uid/gid on the server.

K.C.