httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@lnd.com>
Subject RE: cvs commit: apache-2.0/src/lib/apr/file_io/win32 filestat.c
Date Tue, 20 Jun 2000 04:24:46 GMT
Questinos inline, first is for a unixhead, the rest for Win32 hackers.

> From: wrowe@locus.apache.org [mailto:wrowe@locus.apache.org]
> Sent: Monday, June 19, 2000 10:14 PM
> To: apache-2.0-cvs@apache.org
> Subject: cvs commit: apache-2.0/src/lib/apr/file_io/win32 filestat.c
> 
> 
> wrowe       00/06/19 20:13:31
> 
>   Modified:    src/lib/apr/file_io/win32 filestat.c
>   Log:
>     Whack that bug... stat functions now almost reasonably implemented
>     on Win32... but security dectection issues linger.
>   
>   Revision  Changes    Path
>   1.21      +99 -31    apache-2.0/src/lib/apr/file_io/win32/filestat.c
>   
>   Index: filestat.c
>   ===================================================================
>    ap_status_t ap_getfileinfo(ap_finfo_t *finfo, ap_file_t *thefile)
>    {
>   +    /* If my rudimentary knowledge of posix serves... inode is the absolute
>   +     * id of the file (uniquifier) that is returned by NT as follows:

Uhmmm... follows much later (the three variables... whoops)

>   +     * user and group could be related as SID's, although this would ensure
>   +     * it's own unique set of issues.  All three fields are significantly
>   +     * longer than the posix compatible kernals would ever require.
>   +     * TODO: Someday solve this, and fix the executable flag below the
>   +     * right way with a security permission test (as well as r/w flags.)
>   +     *
>   +     *     dwVolumeSerialNumber
>   +     *     nFileIndexHigh
>   +     *     nFileIndexLow
>   +     */
>   +    finfo->user = 0;
>   +    finfo->group = 0;
>   +    finfo->inode = 0;

Would someone please explain what an inode is, so I am sure I understand it?
nFileIndexHigh/Low is a 64 bit value on NT... and inode is a 16 bit, correct?

>   +    /* Read, write execute for owner
>   +     * In the Win32 environment, anything readable is executable
>   +     * (well, not entirely 100% true, but I'm looking for a way 
>   +     * to get at the acl permissions in simplified fashion.)
>   +     */
>   +    if (FileInformation.dwFileAttributes & FILE_ATTRIBUTE_READONLY) {
>   +        finfo->protection |= S_IREAD | S_IEXEC;
>   +    }
>        else {
>   -        return errno;
>   +        finfo->protection |= S_IREAD | S_IWRITE | S_IEXEC;
>        }

Does anyone have a simple, short implementation of a "can I read, write,
execute, delete, or administer this file" test without bushwacking through
a ton of ACL calls on Win32?  I'll -keep- the readonly test (since that's
a preference, not security per sei) but additionally test based on the
current user's permissions.  This will actually allow us to allow/deny
execute independent of the read flag (sort of :)  Two cases for this, one 
with the open handle, one without.

>    ap_status_t ap_stat(ap_finfo_t *finfo, const char *fname, ap_pool_t *cont)

>       /* Filetype - Directory or file?
>        * Short of opening the handle to the file, the 'FileType' appears
>        * to be unknowable (in any trustworthy or consistent sense.)
>        */

Ick... I'm correct here?  Short of those extreme is the 0x40 attrib bit set on
Win9x, or the dates and size all zero on NT to tag a CHAR/PIPE (worst, we don't
know which is which.)  I think this may be a dead end, unless someone has a
cool hint.

Mime
View raw message