Just a reminder I am subscribed to the Debian User list. Please only respond to the list and not me as well.
On Thu, 2007-03-22 at 18:56 +0200, Juha Jäykkä wrote: > > I've been reading quite a lot on NFSv(234) and I came across a bug in > > Debian and other distros that when all needed daemons (lockd, nfsd, > > idmapd, etc...) You still may have to use "kinit" to refresh your ticket > > after mounting the nfs share. > > This sounds like The Thing: after being away from the computer > for a couple of hours, everything works again. The only difference being > Xscreensaver which refreshed my ticket for me after asking my password to > unlock the screen when I came back... > > I'll look into it more closely, but I *am* confused: using sec=krb5 > should not require anything from the user (kerberos-wise) and I *DID* > have a valid ticket all along. Is there some strange stuff happening if > *my* ticket is older than the host's ticket? You have to remember, Kerberos works on separate levels with regards to host and user. An NFS mount for the machine to be able to mount the NFS export and requiring a ticket, does not give the users access to the home directories. It allows the machine to properly mount the export where ever it is being mounted. What the next thing with user level access, you have to have a proper ticket to access your data over the NFS mount. So a newer (than the hosts you are on) ticket would typically be required. One other thing that absolutely needs to be, time on the machines and the keyserver(s) have to be in-sync. > Why would the relative ages of the tickets matter? Think about "temporary" files being abuse in exploits. With a temp file reaper, you could be opening up your machine or a user to a carefully made exploit. IOW, the user suspends his/her work, the files are in /tmp or /var/tmp etc... the user doesn't come back for a week or so. He/she decides to keep going where they left off... meanwhile the file has been cleared out by a temp file process. Then a user replaces the file name and so on with a carefully built exploit script/file for the user to open up. Yeouch. Yes, kerberos is all about proper tickets with proper ages and expiry and ticket types. There are SO many things that can go wrong and lock out a user from his/her data it isn't even funny. But that forces things to setup proper. Imagine if the machine had to be rebooted after you got your last ticket, which had a lifetime longer than the reboot of this machine. You could be using prior authentication from a completely different ticket server that might not even be used or known any more. But still hashes properly. (yeah a stretch, but still). I had problems when doing Active Directory as the keyserver and man did it suck. > Lastly, is this worth a bug in DBTS or were you specifically referring > to a DBTS bug, the number of which you could not recall? I cannot seem to find anything related to NFSv4 and kerberos in bugs.debian.org... of course I am still quite fuzzy right now. I guess I should pay more attention. I kind of remember it not being a Debian specific problem, but you might want to put things in verbose logging mode and try to trigger the problem. Once you do... grab the log files or results from the screen and submit it pronto. The Debian kernel team is nearing final "release kernel" status. The whole gssapi and krb5p stuff is really finicky, but once the errant things is dealt with it whistles along quite nicely for extended periods. -- greg, [EMAIL PROTECTED] Novell's Directory Services is a competitive product to Microsoft's Active Directory in much the same way that the Saturn V is a competitive product to those dinky little model rockets that kids light off down at the playfield. -- Thane Walkup
