This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: subversion and permissions


On Nov 27 23:31, Denis Excoffier wrote:
> Hello,
> 
> I'm asking for advice because i don't know how to handle this.
> 
> I have access to an svn repository through the "file:" protocol. The
> svn repository is homed on an ntfs disk, with all ACL permissions
> inherited from a top directory: various kinds of Administrators (not
> me) have many rights. A single dedicated group is allowed r/w access,
> and i belong to this group of course, like all my colleagues that also
> have access to this repository.
> 
> Most of my colleagues use Windows tools (TortoiseSVN) and all is ok
> for them.
> 
> I'd like to use Cygwin of course, and we have subversion-1.8.10 (on
> x86) which is in use at other places and seems ok. Indeed, 'svn
> checkout' and more generally all read-only activity does work
> perfectly on this repository. But i do encounter some problems with
> 'svn commit': it always fail with "Permission denied".
> 
> I tried to write directly to the disk and of course it works. The
> issue (to my current understanding) is (details omitted): - svn
> internally uses a temporary file (e.g. the file "current" under the
> folder "db") - the file is created (in fact: truncated to empty) by
> Cygwin with permissions set to '---rwx---': no permissions for user
> (the ACL entries show no mention of any user), rwx for group (and for
> others we don't care) - Cygwin (chmod in fact, called by libapr)
> implements the '---' for user: it insists, using the Deny/Allow
> mechanism described in https://cygwin.com/cygwin-ug-net/ntsec.html,
> that the user will not be capable of reading the file, and... succeeds
> - indeed, the user (i.e. the svn process that created the file) cannot
> read it any more and terminates with permission denied (and repository
> is locked and must be manually "svnadmin recover'ed").

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).

What you're describing above is an effect, not the cause of the problem.
Keep in mind that Cygwin doesn't decide by itself over the permissions.

Who *exactly* creates the temporary file with 070 permissions?  Is your
umask weird?  Otherwise the permission bits are set by the caller of the
open(2) call.  Who's the caller?

> In fact, Windows users do not need to have any personal right on a
> file to be able to read its content: it is enough that they belong to
> a group that has the appropriate access. For Cygwin users, this is not
> the same: permissions for user and permissions for group are separate.

Right, Windows vs. POSIX semantics.

> To make things work today, i had no better idea than patching the
> Cygwin dll in order to temporarily disconnect the insertion of Deny
> rights. It works of course, but it cannot be an option for tomorrow.
> 
> Is there any way to handle this problem cleanly, preferably without
> changing any permissions on the repository? I tried to mount the disk
> noacl, the problem remains exactly the same.

Are you sure?  noacl would stick to windows default permissions
and not try to overwrite them with POSIX perms.  Did you restart
all your own Cygwin processes after setting noacl, or did you
run mount -a and check the result?


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

Attachment: pgpVw2udIdsgB.pgp
Description: PGP signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]