efault ACLs for FILE: ccaches on Windows

Henry B. Hotz hotz at jpl.nasa.gov
Wed Jul 26 14:02:47 EDT 2006

I'm not sure I should get in the middle of this, but I will anyway.

It seems to me that the first question is whether a Windows port  
should behave the way other platforms behave.  How to do that with a  
minimum of platform-specific code seems secondary.

The problem is that the open() libc call on Windows is dangerously  
(IMO) non-POSIX in its behavior.  So the question translates to:  
should Windows file ccaches have the same permission semantics as on  
other platforms?

Speaking as a non-Windows user, I'm in the "Windows is broken, so fix  
it" camp, but others may disagree.  I can't evaluate how significant  
it is that "power users" can read all ccache's, but it doesn't sound  

Based on a side-bar with Jeffrey, it sounds like using a POSIX- 
compliant open() would break a lot of stuff and isn't a viable  
alternative.  Pity.  If that weren't true then a compromise would be  
possible, since it would put the fix in the Windows build system  
rather than the code itself.

On Jul 26, 2006, at 9:02 AM, krbdev-request at mit.edu wrote:

> Date: Wed, 26 Jul 2006 07:57:51 -0400
> From: Sam Hartman <hartmans at MIT.EDU>
> Subject: Re: Default ACLs for FILE: ccaches on Windows
> To: Jeffrey Altman <jaltman at MIT.EDU>
> Cc: Ken Raeburn <raeburn at mit.edu>, "'krbdev at mit.edu'" <krbdev at mit.edu>
> Message-ID: <tslhd14fuio.fsf at cz.mit.edu>
> Content-Type: text/plain; charset=us-ascii
> I am concerned about the complexity of adding this sort of
> platform-specific functionality.  We've tried very hard over the years
> to remove rather than add platform-specific functionality to the file
> ccache.  I don't want to end up supporting ACL APIs for every
> platform.
> I don't see this item as urgent, so I'd prefer to allow it to be
> blocked by a general policy on what platform-specific extensions we
> accept and how we do that.
> --Sam

The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz at jpl.nasa.gov, or hbhotz at oxy.edu

More information about the krbdev mailing list