Mail Archives: cygwin/2005/04/13/10:13:03
On Apr 13 07:24, Eric Blake wrote:
> As a side note, when POSIX requires atomicity of a syscall and cygwin
> can't provide it with respect to Windows, would it at least be possible to
> provide atomicity with respect to other cygwin programs via an
> interprocess mutex managed by cygwin1.dll? Or is this so slow that
> providing the atomicity would noticibly degrade performance in the common
> case?
Yes.
> Instead of writing wrappers around all the syscalls that don't do implicit
> magic, I would instead write a wrapper around stat that undoes cygwin's
> underlying .exe magic. Then I could add cygwin-specific command line
Why? cp and mv are not as dangerous as rm (most of the time, that is).
I wouldn't want cp or mv to ignore .exe, while in case of rm it makes
sense as a security feature.
> One last note - cygwin unlink() still has the POSIX bug I reported earlier
> where calling unlink() on a file in a directory with no write permissions
I think I know how to get this right without having to test the directory
permissions in Cygwin manually. But the change looks somewhat dangerous
to me, so I'm pretty reluctant to change it.
Apparently the Win32 DeleteFile functionality is bound to the DELETE
permission in the file's ACL in the first place. If the current user has
this effective permission set in the file's ACL, the file is deleted.
If the user has no effective DELETE permission in the file's ACL, then the
parent directory's ACL is examined. If the current user has the
FILE_DELETE_CHILD permission set in the parent directory's ACL, the file
is deleted.
If none of these permissions is set, the user gets a "Permission denied".
So, to get POSIX semantics, Cygwin should never set the DELETE flag in
the file's ACL, which right now is coupled to the write permission.
Instead, Cygwin should just rely on the FILE_DELETE_CHILD flag in the
parent directory's ACL which is coupled with write permission on the
directory.
This won't help for already existing files, unless chmod is used on them
and as I said, that sounds somewhat dangerous to me. I won't include it
into 1.5.15, but I think that's something we can think about to include in
1.5.16, if it turns out to be useful.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader mailto:cygwin AT cygwin DOT com
Red Hat, Inc.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -