Front page | perl.perl5.porters |
Postings from June 2008
Abigail wrote:
> On Mon, Jun 09, 2008 at 03:34:23PM +0200, Aristotle Pagaltzis wrote:
>> * Craig A. Berry <craig.a.berry@gmail.com> [2008-06-09 15:05]:
>>> Before Abigail's patch, the Unix copy() did roughly what the
>>> VMS and Win32 syscopy() implementations do: it followed "new
>>> file" semantics and created the target file with permissions
>>> inherited from the target environment.
>> Except, there is no such thing as permissions inherited from the
>> target environment on Unix. Maybe you could consider the exec
>> bits on the directories that are part of a file’s path some kind
>> of permission inheritance, but even that is a bit of a stretch.
>
> Well, one could argue that the umask is "permissions inherited from the
> target environment". And that is what still happens after my patch as
> well. The difference is that before my patch, the permissions of the
> new file *only* depend on umask, it's 0666 & ~umask. After my patch,
> it uses the permissions bits of the source file itstead of 0666, but
> still masks them with ~umask.
VMS has two and sometimes three places permissions are inherited from:
* The process default protection mask.
* [optional] The internal umask() setting for programs written in C.
* Default protection ACL on the target directory if one exists.
VMS has two modes of handling the umask setting, a VMS mode and a UNIX
mode. The default is the VMS mode. I would have to look up the
differences to see exactly what they are.
Windows NTFS also has default protection ACLs on the target directory if
one exists.
In either case, I think that the umask()/stat() API has lower precision
than the native protection settings, so specifying the protections
explicitly can result in much different settings than the default, even
though it may appear to be the same.
Some UNIX systems have ACLs. Is it possible that an ACL entry could
override the protection and cause the test to fail?
> My hope was that there were no effects at all for environments that
> don't have permissions bits, but I've no non-Unix environment to test
> that, nor any significant experience on non-Unix platforms to make any
> predictions, nor was perlport of any help of predicting the behaviour
> on non-Unix systems. (My thought was, if the platform doesn't have
> permissions, it doesn't really matter what the third argument of sysopen
> is).
I know of a few public access VMS systems that you can get access to.
One of them recently had perl 5.10 installed on it.
>>> I don't like the fact that copying from a handle now gives
>>> different behavior permissions-wise than copying from a
>>> filename, but that inconsistency could be ironed out pretty
>>> easily.
>
> I am surprised about this. My patch takes the permissions bit from the
> file handle (either the one passed to copy, or the one after opening
> the source file), and there are tests that check whether the permission
> bits are set correctly when copying from a file handle.
I think that permission bits are mostly simulated on Win32, and have
different meaning on the FAT file system.
On VMS there is not a 1 to 1 relationship between the permission bits of
UNIX and VMS, but they are closer. VMS has a delete permission and a
write permission bit which have different meanings.
The translation of VMS/WIN32 file security into UNIX permission bits
loses information.
Translating UNIX permission bits into VMS/WIN32 causes the underlying
API to guess how to set the missing information.
Regards,
-John
Thread Previous
|
Thread Next