public inbox for
 help / color / mirror / Atom feed
From: Eliot Moss <>
Subject: Re: umask problem: wrong permissions for new files
Date: Fri, 27 Apr 2018 09:27:00 -0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 4/27/2018 4:54 AM, Andrey Repin wrote:
> Greetings, Ulli Horlacher!
>> On Fri 2018-04-20 (07:25), Brian Inglis wrote:
>>> Cygwin supports Windows ACLs as POSIX ACLs, which are also supported by
>>> Linux. Use setfacl to set similar default ACLs (DACLs) on a Linux
>>> directory, rerun your test there, and you should see similar results.
>> (How) can I completly remove ACLs from the cygwin files and directories?
> You CAN, yes.
> However, you will lose any way to access the files, as explained below.
>> The standard UNIX permissions are sufficent for my needs and much easier
>> to handle :-}
> "Standard POSIX" permissions are insufficient even for most basic operations.
> They survive only because removing them would cause even more harm, than
> letting them sit around.
>>> *Never* remove DACLs from any Windows directory which will *ever* be used
>>> with any non-Cygwin Windows program: /undefined behaviour/ will result.
>> Uuups... thanks for the warning!

Let me add this ...

What mostly work for me (occasional gotchas) is this:

I am "moss" and I added a group "Cygwin".  I have admin permissions under Windows.

A typical file acl for me has owner moss and group Cygwin - sometimes I have to
set these manually, particularly if they are created by a Windows program.

Also, typical acls for files print out as:

# owner: moss
# group: Cygwin
group::rwx                              #effective:rw-
group:SYSTEM:r-x                        #effective:r--
group:Cygwin:rwx                        #effective:rw-

This corresponds to Posix permissions 664.  The SYSTEM thing helps insure that
Windows programs, such as my backup program, can read the file.

Here is a typical directory acl:

# owner: moss
# group: Cygwin
# flags: -s-

This is more complex since it is intended to propagate useful permissions to
files crated within the directory.  It is the default entries that help do that.
Note the -s- flag, which encodes the 2000 (set gid) bit of Posix permissions,
enabling propagation of default permissions.  This directory's Posix permissions
are 2775.  Again, the SYSTEM entries are important for me.

A typical file created by a Windows program (Word, in this case) ends up with
this acl:

# owner: moss
# group: moss
# flags: -s-

The Posix permissions read as 2775 (rwxrwsr-x).

Some people like this way of setting things up, some don't.  As they say, YMMV.

Regards - Eliot Moss

Problem reports:
Unsubscribe info:

      reply	other threads:[~2018-04-27  9:27 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-20 10:04 Ulli Horlacher
2018-04-20 12:47 ` Houder
2018-04-20 12:53   ` Houder
2018-04-20 13:07 ` Corinna Vinschen
2018-04-20 13:25 ` Brian Inglis
2018-04-26 14:38   ` Ulli Horlacher
2018-04-27  9:05     ` Andrey Repin
2018-04-27  9:27       ` Eliot Moss [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).