Response to "Re: efault ACLs for FILE: ccaches on Windows"

[Jeffrey Altman]

Hank:

The POSIX open(path, O_CREAT, 0600) that you desire does not exist in
the Microsoft C runtime library.  Microsoft's implementation is:

   int _open(path, flag, pmode) - open or create a file

       Opens the file and prepares for subsequent reading or writing.
       the flag argument specifies how to open the file:
         _O_APPEND -   reposition file ptr to end before every write
         _O_BINARY -   open in binary mode
         _O_CREAT -    create a new file* no effect if file already
                       exists
         _O_EXCL -     return error if file exists, only use with
                       O_CREAT
         _O_RDONLY -   open for reading only
         _O_RDWR -     open for reading and writing
         _O_TEXT -     open in text mode
         _O_TRUNC -    open and truncate to 0 length (must have write
                       permission)
         _O_WRONLY -   open for writing only
         _O_NOINHERIT -handle will not be inherited by child processes.
       exactly one of _O_RDONLY, _O_WRONLY, _O_RDWR must be given

       The pmode argument is only required when _O_CREAT is specified.
       Its flag settings:
         _S_IWRITE -   writing permitted
         _S_IREAD -    reading permitted
         _S_IREAD | _S_IWRITE - both reading and writing permitted
       The current file-permission maks is applied to pmode before
       setting the permission (see umask).

There is no option for setting the UNIX permissions because those
permissions do not exist on Windows.   _open() is implemented as a
call to CreateFile which a SECURITY_ATTRIBUTES structure that only
sets the bInheritHandle value based upon whether or not _O_NOINHERIT
is specified.

The end result is that the ACLs associated with the file are always
the ACLs inherited from the parent directory.  The defaults for this
are fairly broad because Windows applications have traditionally been
developed assuming the user is "Administrator" of the machine.  Many
applications still in use simply won't run if the user is a standard
user without access to the registry, the %SystemRoot% directory tree,
etc.  As a result most users on 2000, XP and 2003 are Power Users if
they are not Administrators.  Microsoft is attempting to fix this in
Vista and it is going to cause a great deal of pain to everyone
involved.

I liked Ken's idea of a krb5 support function stored util/support/
and used as a replacement for open() within the file ccache, replay
ccache, and keytab routines because I thought it did a good job of
striking a balance between code purity in the source files and
providing the necessary security.  The src/lib/krb5/ccache/cc_file.c
implementation already uses a C Preprocessor macro in place of
open() due to the differences between the declarations on POSIX
systems and Windows.  Changing the definition for Windows to use
a support function instead of the C runtime library function does
not appear to be very intrusive.

The question of default ACLs on the file is in some ways similar
to the issues surrounding the use of getenv() putenv() within the
Kerberos libraries.  On Windows the C runtime library when it is
initialized is given a local copy of the process environment.  When
putenv() is called only the local copy is updated.  When the process
calls SetEnvironmentVariable() the C RTL's local copy is not updated.
Therefore the semantics of Kerberos functions that rely on setting
environment variables to control the use of a particular credential
or reply cache or a krb5.conf file are highly unreliable.  The
behaviors all depend upon whether the application and krb5 dll were
built with the same versions of the C RTL or not and which of the
environment variable functions are being used.

There are also issues with differences in behavior of the Kerberos
libraries with regards to file locks.  I think all of these issues
should be addressed at the appropriate time.

Jeffrey Altman


Henry B. Hotz wrote:
> 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 good.
> 
> 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
> 
>