Re: Proposal for file protection extension

[Stewart Greenhill <greenhil@murdoch.edu.au>]

At 07:53 AM 13/12/98 -0500, you wrote:
>Michael van Acken wrote:
>
>> > Date: Fri, 11 Dec 98 10:46:31 EST
>> > From: Mike Griebling <grieblm@trt.allied.com>
>> >
>> > I've attached my proposal for a file protection
>> > extension to the existing Files.Mod interface.
>> > Basically this extension, allows users to read
>> > and set file protection bits in a portable way.
>>
>> a) this file protection scheme is not portable, it's Unix
>>
>
>It's a subset of Unix which I believe is portable.  Every
>OS I'm aware of would support these file attributes.

To an extent, sys/stat.h functions appear to be a kind of "standard" for C
implementations, but these might not actually be supported by the host
operating system. The DOS/Windows FAT / VFAT files systems have a
"read-only" bit which could possibly be used to emulate the S_IWUSR
functionality, but there is no other permissions information in the file
system. This means that unix-style permissions can't really be implemented
on any Microsoft OS other than Windows NT.

The Cygwin32 compiler emulates permissions since it emulates unix. However,
it probably just ignores bits that cannot be implemented. For cygwin32, the
stat mode field is called "st_mode", not "st_basemode". All the mentioned
attributes are supported here.

With some #ifdefs, the sample code may work with many Windows compilers.

For the Borland WIN32 compiler (which is probably closer to the norm for
Windows), stat.h only defines S_I{RWX}USR. There are no definitions for
group and other bits. You could probably #define these to zero, and it
would work.

>>
>> b) it does not even deal with all the bits that Unix typically
>>    associates with a file:
>>
>>               S_ISUID  0004000 set UID bit
>>
>>               S_ISGID  0002000 set GID bit
>>
>>               S_ISVTX  0001000 sticky bit
>
>Exactly.  I wanted to make it portable.
>
>>
>>
>> Does anyone share my opinion that the `Files' module should not be
>> cluttered with OS specific functions?
>>
>
>Who thinks file protection is OS-specific?  Every OS under the
>sun has such protection (or will have it soon).

MS Windows does not support protections. If these were to be added to
files.c, it would be necessary to add a test (during configuration) for
whether sys/stat is supported, and (if so) whether the mode field is
st_mode or st_basemode. There would also need to be a way within the Files
modules of testing whether a given file supports permissions or not,
otherwise you can't tell whether you have the expected functionality. To be
strict about it, this should probably be done on a "per-bit" basis, since
some systems will support some permission bits and not others. This could
be done by simply returning a SET of supported bits. 

The system would need to generate a run-time exception if someone attempts
to set or get permissions when they are not supported by the file (ie. the
file system on which the file is located) or the environment (ie. the C
compiler libraries). Note that this can happen even under Unix since it is
possible that the the program does not have sufficient priveledges to set
the permissions, or that the file is on a file system for which permissions
cannot be set (eg. a mounted DOS partition, CDROM file-system, etc).

- Stewart