Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Date: Wed, 13 Apr 2005 16:12:41 +0200
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: cygwin coreutils-5.3.0-4 rm change breaks Libtool
Message-ID: <20050413141241.GI22241@cygbert.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <041220052251 DOT 26916 DOT 425C50E800071C000000692422007507840A050E040D0C079D0A AT comcast DOT net> <20050413071703 DOT GA22055 AT iam DOT uni-bonn DOT de> <425D1D7F DOT 6080204 AT byu DOT net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <425D1D7F.6080204@byu.net>
User-Agent: Mutt/1.4.2i

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/