On Mon, 2009-03-02 at 13:11 -0600, Will Fiveash wrote: > On Mon, Mar 02, 2009 at 12:19:13PM +0100, Mark Phalan wrote: > > > > On Mon, 2009-03-02 at 11:09 +0100, Mark Phalan wrote: > > > On Fri, 2009-02-27 at 13:13 -0600, Will Fiveash wrote: > > > > On Fri, Feb 27, 2009 at 10:09:09AM +0100, Mark Phalan wrote: > > > > > > > > > > On Thu, 2009-02-26 at 12:00 -0800, Ben Rockwood wrote: > > > > > > Truss posted here: > > > > > > > > > > > > http://www.cuddletech.com/rpcsec-truss.txt > > > > > > > > > > Looks like Shawn figured out your problem. You can see the same issue > > > > > in > > > > > the truss (just look for krb5_set_error_message()). > > > > > > > > > > There probably should be some logic to re-create the directory > > > > > structure > > > > > if it isn't there. Kerberos is just too brittle in this respect. I've > > > > > seen this problem over and over again :( > > > > > > > > Maybe. The question is what paths should krb be responsible for > > > > recreating? Do other native services do this? > > > > > > I probably agree with you that directories created by the package system > > > should be left under the control of the package system. It begs the > > > question though - why are these directories necessary? why not have a > > > flatter directory structure and put the replay caches directly > > > into /var/krb5 ? Perhaps there's a good reason I don't know about. > > > > Or even better move back to having the replay caches on tmpfs (requires > > 6794523). > > Yep, the reason rcaches moved from tmpfs to /var/krb5 is here: > 4917510 default rcache location should not be on tmpfs > > There was an PSARC case: > PSARC 2003/752 Placing Kerberos Replay Cache in /var > > Here is the bottom line from the discussions about this case: > > Here are the proposed permissions from the SUNWkrbr prototype_com file: > > d none var/krb5/rcache 1777 root sys > d none var/krb5/rcache/root 700 root sys > > The permission will prevent anyone from molesting the rcaches in the > var/krb5/rcache/root dir. > > So at the time we thought it more secure to have a root rcache dir that > only root could read/write.
Ok. I guess that makes sense. > > Now when/if we implement the logic for: > 6794523 rcache could skip fsync(2)s in common cases with a dynamic skew > concept > > and the potential boot window replay attack goes away, then yes it would > better to move the rcaches back to tmpfs. It certainly would be a nice feature. -M >
