ACL: Why SYSTEM doesn't have full access set on newly created files?

ACL: Why SYSTEM doesn't have full access set on newly created files?

[Kacper Michajlow]

Hi,

I know that Cygwin tries to emulate UNIX permissions using ACL. But I don't
understand why SYSTEM doesn't have Full Control allowed or even modify.
Shouldn't generally SYSTEM have access to everything?

I have cloned git repository of UWP application, and deployment fails in VS
with error:
"DEP0700: Registration of the app failed. [0x80070005] Deployment Register
operation with target volume F: on Package ... from:  (AppxManifest.xml)
 failed with error 0x80070005."
It is easily fixable by adding Full Control for SYSTEM on all files, but
that wasn't my first idea, so it took some time :) Long story short, it
fails and might be not obvious for the user why, at the first glance.

Also when accessing ACL from Explorer it throws:
"The permissions on <directory> are incorrectly ordered, which may cause
some entries to be ineffective."
And forces me to reorder them if I want to edit.

That said, I have three questions:
1. Could Cygwin by default give SYSTEM full control? If not, why?
2. Could Cygwin put ACL in order, so Windows doesn't complain about it?
3. Do we need "NULL SID" entry?

-Kacper

Re: ACL: Why SYSTEM doesn't have full access set on newly created files?

[Biswapriyo Nath]

[-- Attachment #1: Type: text/plain, Size: 560 bytes --]

Same issue here. I use git in msys2 for correct file permissions. Also
if I install cygwin and reinstall Windows 10 OS then Windows programs
can not edit any cygwin files. I have to take ownership with takeown
and icacls commands then chmod the files.

I found a temporary workaround. 1. Add `noacl` option in `/etc/fstab`
file in cygwin. But this only fixes the file permission in Windows
drives . 2. In newlib-cygwin source code, remove
`FILE_PERSISTENT_ACLS` flag and add `MOUNT_NOACL` flag in
winsup/cygwin/mount.cc file. Attached patch file as reference.

[-- Attachment #2: cygwin-mount-disable-acl.patch --]
[-- Type: text/plain, Size: 2129 bytes --]

diff --git a/winsup/cygwin/mount.cc b/winsup/cygwin/mount.cc
index e034981..7ba6f4a 100644
--- a/winsup/cygwin/mount.cc
+++ b/winsup/cygwin/mount.cc
@@ -332,7 +332,6 @@ fs_info::update (PUNICODE_STRING upath, HANDLE in_vol)
 #define MINIMAL_WIN_NTFS_FLAGS (FILE_CASE_SENSITIVE_SEARCH \
 				| FILE_CASE_PRESERVED_NAMES \
 				| FILE_UNICODE_ON_DISK \
-				| FILE_PERSISTENT_ACLS \
 				| FILE_FILE_COMPRESSION \
 				| FILE_VOLUME_QUOTAS \
 				| FILE_SUPPORTS_SPARSE_FILES \
@@ -473,13 +472,13 @@ mount_info::create_root_entry (const PWCHAR root)
   sys_wcstombs (native_root, PATH_MAX, root);
   assert (*native_root != '\0');
   if (add_item (native_root, "/",
-		MOUNT_SYSTEM | MOUNT_IMMUTABLE | MOUNT_AUTOMATIC)
+		MOUNT_SYSTEM | MOUNT_IMMUTABLE | MOUNT_AUTOMATIC | MOUNT_NOACL)
       < 0)
     api_fatal ("add_item (\"%s\", \"/\", ...) failed, errno %d", native_root, errno);
   /* Create a default cygdrive entry.  Note that this is a user entry.
      This allows to override it with mount, unless the sysadmin created
      a cygdrive entry in /etc/fstab. */
-  cygdrive_flags = MOUNT_NOPOSIX | MOUNT_CYGDRIVE;
+  cygdrive_flags = MOUNT_NOPOSIX | MOUNT_CYGDRIVE | MOUNT_NOACL;
   strcpy (cygdrive, CYGWIN_INFO_CYGDRIVE_DEFAULT_PREFIX "/");
   cygdrive_len = strlen (cygdrive);
 }
@@ -508,12 +507,12 @@ mount_info::init (bool user_init)
       if (!got_usr_bin)
       {
 	stpcpy (p, "\\bin");
-	add_item (native, "/usr/bin", MOUNT_SYSTEM | MOUNT_AUTOMATIC);
+	add_item (native, "/usr/bin", MOUNT_SYSTEM | MOUNT_AUTOMATIC | MOUNT_NOACL);
       }
       if (!got_usr_lib)
       {
 	stpcpy (p, "\\lib");
-	add_item (native, "/usr/lib", MOUNT_SYSTEM | MOUNT_AUTOMATIC);
+	add_item (native, "/usr/lib", MOUNT_SYSTEM | MOUNT_AUTOMATIC | MOUNT_NOACL);
       }
     }
 }
@@ -1131,7 +1130,7 @@ mount_info::from_fstab_line (char *line, bool user)
     return true;
   cend = find_ws (c);
   *cend = '\0';
-  unsigned mount_flags = MOUNT_SYSTEM;
+  unsigned mount_flags = MOUNT_SYSTEM | MOUNT_NOPOSIX | MOUNT_NOACL;
   if (!strcmp (fs_type, "cygdrive"))
     mount_flags |= MOUNT_NOPOSIX;
   if (!strcmp (fs_type, "usertemp"))

Re: ACL: Why SYSTEM doesn't have full access set on newly created files?

[Andrey Repin]

Greetings, Kacper Michajlow!

> I know that Cygwin tries to emulate UNIX permissions using ACL. But I don't
> understand why SYSTEM doesn't have Full Control allowed or even modify.
> Shouldn't generally SYSTEM have access to everything?

This is because basic POSIX permissiosn are that -stupid +limited. And because
in Windows there's no inherent super-user. Even SYSTEM do not have powers to go
against set permissions.
POSIX permissions in Cygwin are emulated using Windows ACL.
Part of the answer can be found in https://cygwin.com/faq.html#faq.using.ssh-pubkey-stops-working
The rest is in https://cygwin.com/cygwin-ug-net/ntsec.html

> I have cloned git repository of UWP application, and deployment fails in VS
> with error:
> "DEP0700: Registration of the app failed. [0x80070005] Deployment Register
> operation with target volume F: on Package ... from:  (AppxManifest.xml)
>  failed with error 0x80070005."
> It is easily fixable by adding Full Control for SYSTEM on all files, but
> that wasn't my first idea, so it took some time :) Long story short, it
> fails and might be not obvious for the user why, at the first glance.

It is easily fixable by mounting directories outside Cygwin tree with "noacl" flag.
It is even required to do so, if you expect interoperation between Cygwin and
native tools.

> Also when accessing ACL from Explorer it throws:
> "The permissions on <directory> are incorrectly ordered, which may cause
> some entries to be ineffective."
> And forces me to reorder them if I want to edit.

Don't do that on Cygwin directory tree, you break Cygwin doing this.

> That said, I have three questions:
> 1. Could Cygwin by default give SYSTEM full control? If not, why?

Answered multiple time in the last 20 years. Read the docs.

> 2. Could Cygwin put ACL in order, so Windows doesn't complain about it?

They are in correct order. Just not canonical order, which Explorer only
supports.

> 3. Do we need "NULL SID" entry?

Yes.

> Documentation:        https://cygwin.com/docs.html


-- 
With best regards,
Andrey Repin
Friday, March 27, 2020 12:31:49

Sorry for my terrible english...

Re: ACL: Why SYSTEM doesn't have full access set on newly created files?

[Kacper Michajlow]

 > It is easily fixable by mounting directories outside Cygwin tree with
"noacl" flag.
> It is even required to do so, if you expect interoperation between Cygwin
and
> native tools.

Indeed, this is acceptable workaround for me. Then again it is not really
interoperable out of the box, even tho it may looks like. I mean all
Windows drives are mounted, you can easily jump through all directories,
mess with them until you find that it doesn't work and it is " required" to
access those files differently. One may be fooled by the seemingly no
boundary between Cygwin and Windows.

> Don't do that on Cygwin directory tree, you break Cygwin doing this.

I was talking about project cloned outside Cygwin tree, by using Cygwin's
git. I do understand that Cygwin sysroot is it's own thing.
Also the Cygwin tree have let say "normal" permissions set. I mean there is
not deny on SYSTEM and so on.

> Answered multiple time in the last 20 years. Read the docs.

If it were so easy to find. And it was changed like 5 years ago how ACLs
are handled, so I really doubt it was described 20 years ago. I just wanted
to understand why SYSTEM described in Cygwin's docs as "A special account
which has all kinds of dangerous rights, sort of an uber-root account."
have those rights limited.

> They are in correct order. Just not canonical order, which Explorer only
supports.

I was not implying they are in incorrect order... The question was, could
Cygwin apart from having permissions in correct order, have them in
Explorer compatible order also?

> Yes.

Thank you for comprehensive answer.

-Kacper

Re: ACL: Why SYSTEM doesn't have full access set on newly created files?

[Andrey Repin]

Greetings, Kacper Michajlow!

>> It is easily fixable by mounting directories outside Cygwin tree with
>> "noacl" flag.
>> It is even required to do so, if you expect interoperation between Cygwin
>> and native tools.

> Indeed, this is acceptable workaround for me. Then again it is not really
> interoperable out of the box, even tho it may looks like.

Interoperabily with native tools was never a stated goal of Cygwin project.
Although it is trying to comply where possible.

> I mean all Windows drives are mounted, you can easily jump through all
> directories, mess with them until you find that it doesn't work and it is "
> required" to access those files differently. One may be fooled by the
> seemingly no boundary between Cygwin and Windows.

I can agree that default /cygdrive mount options needs a revision.

>> Don't do that on Cygwin directory tree, you break Cygwin doing this.

> I was talking about project cloned outside Cygwin tree, by using Cygwin's
> git. I do understand that Cygwin sysroot is it's own thing.
> Also the Cygwin tree have let say "normal" permissions set. I mean there is
> not deny on SYSTEM and so on.

>> Answered multiple time in the last 20 years. Read the docs.

> If it were so easy to find. And it was changed like 5 years ago how ACLs
> are handled, so I really doubt it was described 20 years ago. I just wanted
> to understand why SYSTEM described in Cygwin's docs as "A special account
> which has all kinds of dangerous rights, sort of an uber-root account."
> have those rights limited.

If you find documentation incorrect or unclear, please ask any questions you
have or suggest patches.

>> They are in correct order. Just not canonical order, which Explorer only
>> supports.

> I was not implying they are in incorrect order... The question was, could
> Cygwin apart from having permissions in correct order, have them in
> Explorer compatible order also?

As I said, if you fix /cygdrive mount options to include noacl flag,
permissions control will be deferred to operating system.
This will amend some of the interoperability issues.


-- 
With best regards,
Andrey Repin
Friday, March 27, 2020 18:19:43

Sorry for my terrible english...