On Nov 28 17:17, Achim Gratz wrote: > Corinna Vinschen writes: > > I don't grok that. If you chmod one of your own files 070 or 060, and > > then try to read it, you get a permission denied error. This is > > perfectly ok from a POSIX POV. The problem here is, why does our own > > libapr chmod to 070 at all? If libapr does it, and if this is known > > behaviour, svn should know this and behave accordingly (re-chmoding > > for instance). > > Without having looked at the code, the 070 mode could be an effect of > forced (inherited) ownership and ACL on the filesystem in combination > with a non-ACL-aware application. Another possibility is a setup where > the user has modify access via some group, but is explicitly forbidden > to create or modify ACL (sometimes they are even disallowed to read > them).
But then the application couldn't have written a modified POSIX ACL with user deny ACE. > While the file that gets created in this manner can definitely > be changed by the user as far as Windows is concerned, from a POSIX > perspective the user is explicitly disallowed to access it in any way. ...only if an application checks the POSIX permission bits. The access(2) call and the open(2) call are bound by Windows rules. If the user deny ACE has not been written, both calls would succeed because the Windows ACL allows access. The user deny ACE can only have been written then, if either the Windows default perms contain them (unlikely), or a Cygwin application or librayr has called open(file, open_mode, 0070) or chmod(file, 0070), or one of their variations (openat, fchmod, etc). Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
pgpseABVA2sFf.pgp
Description: PGP signature
