Solved: Kerberised NFS

[Nicolas Williams]

On Fri, Feb 13, 2009 at 08:56:43AM +0000, Peter Eriksson wrote:
> Edward Irvine <eirvine at tpg.com.au> writes:
> >I also did a little experiment. After logging in to the target  
> >machine, (with the GSSAPIDelegateCredentials working and all), I ran  
> >the "kdestroy" command. As expected, my home directory became  
> >immediately unreadable until I got a new TGT with the "kinit"  
> >command. Cool...

Sorry I'm late to this thread (and thanks Doug!).

> Next you'll discovery the fun side effects of having a Secure NFS'd
> home directory (I've been running with that for about a year now).

I've been running with one for a long time also.

> Most things work just as expected but then there are the warts...
> 
> Firefox:
>   When Firefox loses access to $HOME (for example if you are away from
>   your computer long enough for the ticket to expire) then the Google
>   search box will magically stop working. Solution: Restart Firefox.

I've never noticed this.  Partly that's because I have renewable TGTs
with a fairly long renewable lifetime so that ktkt_warnd does the right
thing and either I'm never away for too long or I logout if I will be.

> Thunderbird:
>   When Thunderbird loses access to $HOME due to expiring tickets then
>   it will you from being able to delete new mail in your IMAP inboxes.
>   New mail will show up fine though... Solution: Restart Thunderbird.

I use mutt :)

> xscreensaver:
>   When $HOME goes away then xscreensaver will fail you launch the
>   password dialog application when you wish to login again (since
>   it can't read the .Xauthority file   in your $HOME so it will
>   not be allowed access to your X server). Blank window forever...
>   Solution: ssh in from another machine and 'kill' xscreensaver.

Never had this problem on Solaris.

> crontab jobs, Grid Engine Jobs:
>   You'd better make sure you have tickets on the machines where they
>   are going to start your jobs and that the tickets won't expire
>   while the jobs are running. Solution: ?

Yup, this is a problem.  Arguably you shouldn't have cron jobs if they
will need to use authentication mechanisms that either require
interaction every time or which use credentials that can expire such
that interaction is required to obtain fresh ones.  Or you need to be
very aware of the issue.  Or the system needs to give you a way to cache
your password/keys for cronjobs.  None of those options is very
satisfying.

> ssh with S/Key (one time password):
>   Sure, you are let in after a successful authentication. But you will
>   still need to enter your password to get the ticket - allowing someone
>   to sniff it...

I'm not sure I get this one.

But ssh with pubkey userauth does fail if your home directory can't be
accessed on the remote system (Solaris' sshd does a seteuid(your-UID)
before accessing your authorized_keys file, IIRC).

Nico
--