Re: Howto to backup and restore windows ACL?

[Andrey Repin via Cygwin]

Greetings, matth...@gmx.li!

> Hello,

> Is it possible to save and restore the windows acl?

Yes, but it is not a question for this list.

> My issue is that I can backup my files with rsync to my Linux Server.
> But if I restore it the ownership and access rights are changed.
> Unfortunately I'm still on backuppc 3.3 and can't ust rsync with --acl and
> --xattr.

> If I could extract the acls to a file, as "ntfssecaudit -b C:" would do and
> restore them later as "ntfssecaudit -s C:" would do would be great.

Look for tools like subinacl.


-- 
With best regards,
Andrey Repin
Thursday, February 29, 2024 15:38:00

Sorry for my terrible english...


-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Howto to backup and restore windows ACL?

[Matthias--- via Cygwin]

Hello,

Is it possible to save and restore the windows acl?

My issue is that I can backup my files with rsync to my Linux Server.
But if I restore it the ownership and access rights are changed. Unfortunately 
I'm still on backuppc
3.3 and can't ust rsync with --acl and --xattr.

If I could extract the acls to a file, as "ntfssecaudit -b C:" would do and 
restore them later as
"ntfssecaudit -s C:" would do would be great.

Br
Matthias


-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Howto fix C:\cygwin acl after backup/restore?

[Brian Inglis via Cygwin]

On 2023-04-07 14:36, Thomas Schweikle via Cygwin wrote:
How can C:\cygwin ACL be fixed after a backup/restore (file by file, not image). 
The program seems to force canonical ACL while restoring.

How do i get back ACL as they are right after installing cygwin?
Docs did not help here. They discussed Windows-ACL to POSIX-ACL or simple 
rwxrwxrwx POSIX rights used on most *nix machines, but at no point where 
concrete ACL shown as they are supposed to be applied to the installed C:\cygwin 
tree.

Any idea? Any script? Any existing command to recreate recommended ACLs?


For the Cygwin root directory, normal u+rwx,go+rx perms are sufficient.

For other Cygwin files where perms are significant, you should use Cygwin 
backup/restore utilities e.g. rsync, tar, cpio, etc.


Without some image of Cygwin ACLs, you can not restore them as they were, as in 
the setfacl(1) example:


$ getfacl source_file | setfacl -f - target_file

or an equivalent en masse.

For user created files and scripts, use relevant normal permissions.

For installed files, if you have a complete and current package cache directory, 
you can compare the installation to the latest archive of each package under 
/{x86_64,noarch}/release/ looping thru:


tar -d -C / -f 
/{x86_64,noarch}/release//.../...--.tar.*z*

e.g.

$ tar -d -C / -f ~/mirror/x86_64/release/bash/bash-4.4.12-3.tar.xz
/bin/tar: etc/postinstall/bash.sh: Warning: Cannot stat: No such file or 
directory
usr/bin/bash.exe: Uid differs
usr/bin/bash.exe: Gid differs
usr/bin/bashbug: Mode differs
usr/bin/bashbug: Uid differs
usr/bin/sh.exe: Not linked to usr/bin/bash.exe
usr/include/bash/alias.h: Uid differs
...

which is very verbose, or do your own perms comparison vs the outputs from 
looping thru:


tar -tv -C / -f 
/{x86_64,noarch}/release//.../...--.tar.*z*

(*always remembering that all Cygwin installation tar file paths are relative to 
the Cygwin root directory / and need adjusted for use*) sort and group the files 
and directories which differ by tar permissions, and feed the lists of files and 
directories in a loop to e.g.:


/bin/xargs -P `nproc` -a .lst /bin/chmod 

to safely batch and parallelize the changes, or background each  command 
in the loop:


/bin/xargs -a .lst /bin/chmod  &

to parallelize the workload.

The Windows directory cache will buffer the changes, and it might be good to:

$ sync -f /usr /etc

to flush updates to disk: the second arg, if to the same file system, may have 
to wait until the first has completed, unless the command detects that.


--
Take care. Thanks, Brian Inglis  Calgary, Alberta, Canada

La perfection est atteinte   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry

--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Howto fix C:\cygwin acl after backup/restore?

[Thomas Schweikle via Cygwin]

Hi!

How can C:\cygwin ACL be fixed after a backup/restore (file by file, not 
image). The program seems to force canonical ACL while restoring.


How do i get back ACL as they are right after installing cygwin?

Docs did not help here. They discussed Windows-ACL to POSIX-ACL or 
simple rwxrwxrwx POSIX rights used on most *nix machines, but at no 
point where concrete ACL shown as they are supposed to be applied to the 
installed C:\cygwin tree.


Any idea? Any script? Any existing command to recreate recommended ACLs?
--
Thomas



OpenPGP_0x27AE2304B4974851.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: ACL

[Brian Inglis via Cygwin]

On 2023-02-21 06:51, Thomas Wolff via Cygwin-apps wrote:

Am 21.02.2023 um 14:10 schrieb Jonathan Chapman-Moore via Cygwin-apps:


ML cygwin-apps is for packagers issues, not general distro or features 
discussion, moving to cygwin for followup.



I was wondering when ACL was going to be added to Cygwin?



It's long been available, see /bin/[gs]etfacl


Cygwin has always had to deal with Windows ACLs and ACEs, mostly behind the 
scenes following a Solaris model until 1.7, moving towards POSIX in 2.4, then 
more comprehensively and overtly from 2.5, to provide RFC and POSIX compliance, 
reducing Solaris influence, and better NIS, NFS, and Samba support.

See referenced and earlier:

https://cygwin.com/cygwin-ug-net/ov-new.html#ov-new2.5

https://cygwin.com/cygwin-ug-net/ntsec.html

--
Take care. Thanks, Brian Inglis  Calgary, Alberta, Canada

La perfection est atteinte   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry

--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: How to disable the default bypass of the ACL permissions checking in Cygwin

[Achim Gratz]

Andrey Repin via Cygwin writes:
> That's literally not possible. More likely explanation is that Administrators
> group have full access to the object in question.

They don't.  The issue at hand is that Cygwin uses SeBackupPrivilege and
SeRestorePrivilege if otherwise the object in question would not be
accessible.  The moral of the story is to drop those privileges /
capabilities when you don't need them via cygdrop or just don't use an
administrative account that comes with them in the first place.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: How to disable the default bypass of the ACL permissions checking in Cygwin

[Andrey Repin via Cygwin]

Greetings, Sandy!

> We are from the NGO Centro de Autonomia Digital (CAD) based in Quito,
> Ecuador. We have been using Msys2 to test our project Coyim
> (http://github.com/coyim/coyim) in Windows environments.

> The tests are currently running on GitHub Actions, using the Windows
> Server 2019 Datacenter.

> We have one specific test case that is failing because of interesting
> behavior in Msys2. The full description of the issue is available at the
> following link:

> https://github.com/msys2/msys2-runtime/issues/45

> Thanks to the help of one of the Msys2 developers, we found that Cygwin
> bypasses the checking of the Windows ACL permissions when it runs with
> administrative privileges.

That's literally not possible. More likely explanation is that Administrators
group have full access to the object in question.

Please provide the output from icacls and getfacl utilities.

> We would like to know if it is possible to change this behavior of
> Cygwin or at least have his point of view of how we could control the
> permissions even in this scenario.

Unless you can supply an adequate test case, this looks more like
misunderstanding of sort.


-- 
With best regards,
Andrey Repin
Tuesday, May 25, 2021 22:39:27

Sorry for my terrible english...


-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

How to disable the default bypass of the ACL permissions checking in Cygwin

[Sandy via Cygwin]

Hi there,

We are from the NGO Centro de Autonomia Digital (CAD) based in Quito,
Ecuador. We have been using Msys2 to test our project Coyim
(http://github.com/coyim/coyim) in Windows environments.

The tests are currently running on GitHub Actions, using the Windows
Server 2019 Datacenter.

We have one specific test case that is failing because of interesting
behavior in Msys2. The full description of the issue is available at the
following link:

https://github.com/msys2/msys2-runtime/issues/45

Thanks to the help of one of the Msys2 developers, we found that Cygwin
bypasses the checking of the Windows ACL permissions when it runs with
administrative privileges.

We would like to know if it is possible to change this behavior of
Cygwin or at least have his point of view of how we could control the
permissions even in this scenario.

Thank you very much for your help on this, and thanks to all the team
behind the amazing Cygwin product.

Cheers.




-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Fwd: Fwd: Switching to posix with no acl

[Jim McNamara via Cygwin]

-- Forwarded message -
From: Jim McNamara 
Date: Sat, Nov 14, 2020, 7:26 PM
Subject: Re: Fwd: Switching to posix with no acl
To: René Berber 




On Sat, Nov 14, 2020, 7:17 PM René Berber via Cygwin 
wrote:

> On 11/14/2020 12:37 PM, Jim McNamara via Cygwin wrote:
>
> > Since there are no adduser or addgroup, I guess I'd create those files
> > manually off /etc.
>
> I think the recommended way is using the mkpasswd command.  Actually the
> recommended procedure is not to use anything.
>
> Just run that command and take a look at the output.  You have to filter
> out most lines, only add the user you want.
>
> Now run it with --help, you'll see you can list 'local' users AND domain
> users.  I put quotes on local because you can also specify local to
> which computer (as long as it is running SMB, I think).
>
> Its about the same for groups: mkgroup.
>
> Hope this helps a little.
> --
> R.Berber
> --
> Problem reports:  https://cygwin.com/problems.html
> FAQ:  https://cygwin.com/faq/
> Documentation:https://cygwin.com/docs.html
> Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple


Hi  R. Berber-

Thanks for the cool info. Can't wait to check it out :-)

Robo-loki


Hi R.


Yes. 'The recommendation is to not use anything.'

There are too many accounts specific to the OS like SYSTEM.

I think they serve a purpose. e.g. a process can run as system.

I vote for leaving well enough alone on this one.

I will just set permission at command line in mintty for stuff like ssh
authorized_keys etc. and not touch permission outside of mintty.

Have a cool night.

Thanks,
Robo-loki
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Fwd: Switching to posix with no acl

[René Berber via Cygwin]

On 11/14/2020 12:37 PM, Jim McNamara via Cygwin wrote:


Since there are no adduser or addgroup, I guess I'd create those files
manually off /etc.


I think the recommended way is using the mkpasswd command.  Actually the 
recommended procedure is not to use anything.


Just run that command and take a look at the output.  You have to filter 
out most lines, only add the user you want.


Now run it with --help, you'll see you can list 'local' users AND domain 
users.  I put quotes on local because you can also specify local to 
which computer (as long as it is running SMB, I think).


Its about the same for groups: mkgroup.

Hope this helps a little.
--
R.Berber
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Fwd: Switching to posix with no acl

[Jim McNamara via Cygwin]

-- Forwarded message -
From: Jim McNamara 
Date: Sat, Nov 14, 2020, 1:37 PM
Subject: Fwd: Switching to posix with no acl
To: Cygwin 




-- Forwarded message -
From: Jim McNamara 
Date: Sat, Nov 14, 2020, 12:57 AM
Subject: Switching to posix with no acl
To: Cygwin 


Hi all

Since there are no adduser or addgroup, I guess I'd create those files
manually off /etc.

Then I'd run passwd.

After that put in /etc/fstab

none /cygdrive cygdrive binary, posix=0, noacl, user 0 0

Close all processes.

That would give me a posix permission set up, right?

I read something about windows ignoring some dos bit with a file permission
but that is outside of cygwin...right?

Lastly, with acl you open an administrator cmd shell. With posix can I
escalate to root and stay away from admin cmd shell?

Is anyone else using posfix setup in general or mostly acl?

Thanks for any help!
Roboloki

Sat. Nov. 14 1:35 pm

Hi all-

I found in the manual about the execute bit permission being ignored in
filesystems with acl. That answered one question above. I can just take
advantage of how exe heuristics work.

If I find myself in a position where it needs administrator rights via a
shell, will it interfere with my posix permissions, users, or groups once
the /etc/groups and /etc/password and fstab are already setup?

Did the fstab entry above look okay for posix permission?

Thanks for any assistance !
Roboloki

Sat. Nov. 14, 1:45 PM

HI all -

I had a privilege escalation window come up for instance when running a
system supplied configure script for sshd ( I think ). It gave the choices
yes or no prompting to choose carefully for noacl permission mode or acl
translation setup. I think that prompt is very good. Will it (administrator
mode) always at least ask or identify which type of setup if required?

Thanks as always,
Robo-loki
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Fwd: Switching to posix with no acl

[Jim McNamara via Cygwin]

-- Forwarded message -
From: Jim McNamara 
Date: Sat, Nov 14, 2020, 12:57 AM
Subject: Switching to posix with no acl
To: Cygwin 


Hi all

Since there are no adduser or addgroup, I guess I'd create those files
manually off /etc.

Then I'd run passwd.

After that put in /etc/fstab

none /cygdrive cygdrive binary, posix=0, noacl, user 0 0

Close all processes.

That would give me a posix permission set up, right?

I read something about windows ignoring some dos bit with a file permission
but that is outside of cygwin...right?

Lastly, with acl you open an administrator cmd shell. With posix can I
escalate to root and stay away from admin cmd shell?

Is anyone else using posfix setup in general or mostly acl?

Thanks for any help!
Roboloki

Sat. Nov. 14 1:35 pm

Hi all-

I found in the manual about the execute bit permission being ignored in
filesystems with acl. That answered one question above. I can just take
advantage of how exe heuristics work.

If I find myself in a position where it needs administrator rights via a
shell, will it interfere with my posix permissions, users, or groups once
the /etc/groups and /etc/password and fstab are already setup

Did the fstab entry above look okay for posix permission?

Thanks for any assistance !
Roboloki
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Switching to posix with no acl

[Jim McNamara via Cygwin]

Hi all

Since there are no adduser or addgroup, I guess I'd create those files
manually off /etc.

Then I'd run passwd.

After that put in /etc/fstab

none /cygdrive cygdrive binary, posix=0, noacl, user 0 0

Close all processes.

That would give me a posix permission set up, right?

I read something about windows ignoring some dos bit with a file permission
but that is outside of cygwin...right?

Lastly, with acl you open an administrator cmd shell. With posix can I
escalate to root and stay away from admin cmd shell?

Is anyone else using posfix setup in general or mostly acl?

Thanks for any help!
Roboloki
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Fwd: Objects in ACL cygwin win 10

[Andrey Repin via Cygwin]

Greetings, Jim McNamara!

Please no top-posting in this list.


>> On 2020-10-23 21:49, Jim McNamara via Cygwin wrote:
>> > On Fri, Oct 23, 2020, 10:06 PM Eliot Moss wrote:
>>
>> >> I have to admit I am not 100% sure what you are asking, but I am careful
>> >> to grant SYSTEM access so
>> >> that my backup program can access and save a copy of virtually
>> everything
>>
>> > Thanks for you and Brian helping me.
>> > I used icacls cygwin /q /c /t reset
>>
>> You have to be very careful using icacls and other Windows commands with
>> Cygwin
>> ACLs as
>>
>> "ICACLS preserves the canonical ordering of ACE entries:
>> Explicit denials
>> Explicit grants
>> Inherited denials
>> Inherited grants"
>>
>> and Cygwin's POSIX ACLs may or may not obey this canonical order; Windows
>> File
>> Explorer often does not consider Cygwin ACLs in what it considers canonical
>> order and requires them to be reordered, which breaks the Cygwin
>> permissions.
>>
>> Ah, that "NT AUTHORITY/SYSTEM" SID, normally paired with
>> BUILTIN/Administrators,
>> as users, groups, or both:
>>
>> $ ls -dl /proc/cygdrive/c/Users/; echo; getfacl /proc/cygdrive/c/Users/;
>> echo;
>> icacls C:/Users/
>> drwxr-xr-x+ 1 SYSTEM SYSTEM 0 Apr 13  2020 /proc/cygdrive/c/Users/
>>
>> # file: /proc/cygdrive/c/Users/
>> # owner: SYSTEM
>> # group: SYSTEM
>> user::rwx
>> group::r-x
>> group:Administrators:rwx#effective:r-x
>> group:Users:r-x
>> mask::r-x
>> other::r-x
>> default:user::rwx
>> default:group::---
>> default:group:Administrators:rwx#effective:r-x
>> default:group:Users:r-x
>> default:mask::r-x
>> default:other::r-x
>>
>> C:/Users/ NT AUTHORITY\SYSTEM:(OI)(CI)(F)
>>   BUILTIN\Administrators:(OI)(CI)(F)
>>   BUILTIN\Users:(RX)
>>   BUILTIN\Users:(OI)(CI)(IO)(GR,GE)
>>   Everyone:(RX)
>>   Everyone:(OI)(CI)(IO)(GR,GE)
>>
>> Successfully processed 1 files; Failed processing 0 files
>>

> Yes, I see now what you are saying. Didn't know why it behaves like that.
> Do you reccomend:

> A. Noacl option  in fstab
> B. Reinstall and leave icacls in windows alone so I can deploy in future
> with runtime

C. Reinstall Cygwin into a new directory (or backup the current one and
reinstall). Use noacl option for directories outside Cygwin tree (i.e.
/cygdrive).


-- 
With best regards,
Andrey Repin
Sunday, October 25, 2020 12:07:33

Sorry for my terrible english...

--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Fwd: Objects in ACL cygwin win 10

[Brian Inglis]

On 2020-10-24 01:09, Jim McNamara via Cygwin wrote:
> On Sat, Oct 24, 2020, 3:02 AM Jim McNamara wrote:
>> On Sat, Oct 24, 2020, 12:46 AM Brian Inglis wrote:
>>> On 2020-10-23 21:49, Jim McNamara via Cygwin wrote:
 On Fri, Oct 23, 2020, 10:06 PM Eliot Moss wrote:

> I have to admit I am not 100% sure what you are asking, but I am 
> careful to grant SYSTEM access so that my backup program can access
> and save a copy of virtually everything

 Thanks for you and Brian helping me.
 I used icacls cygwin /q /c /t reset

>>> You have to be very careful using icacls and other Windows commands with
>>> Cygwin
>>> ACLs as
>>>
>>> "ICACLS preserves the canonical ordering of ACE entries:
>>> Explicit denials
>>> Explicit grants
>>> Inherited denials
>>> Inherited grants"
>>>
>>> and Cygwin's POSIX ACLs may or may not obey this canonical order; Windows
>>> File
>>> Explorer often does not consider Cygwin ACLs in what it considers
>>> canonical
>>> order and requires them to be reordered, which breaks the Cygwin
>>> permissions.
>>>
>>> Ah, that "NT AUTHORITY/SYSTEM" SID, normally paired with
>>> BUILTIN/Administrators,
>>> as users, groups, or both:
>>>
>>> $ ls -dl /proc/cygdrive/c/Users/; echo; getfacl /proc/cygdrive/c/Users/;
>>> echo;
>>> icacls C:/Users/
>>> drwxr-xr-x+ 1 SYSTEM SYSTEM 0 Apr 13  2020 /proc/cygdrive/c/Users/
>>>
>>> # file: /proc/cygdrive/c/Users/
>>> # owner: SYSTEM
>>> # group: SYSTEM
>>> user::rwx
>>> group::r-x
>>> group:Administrators:rwx#effective:r-x
>>> group:Users:r-x
>>> mask::r-x
>>> other::r-x
>>> default:user::rwx
>>> default:group::---
>>> default:group:Administrators:rwx#effective:r-x
>>> default:group:Users:r-x
>>> default:mask::r-x
>>> default:other::r-x
>>>
>>> C:/Users/ NT AUTHORITY\SYSTEM:(OI)(CI)(F)
>>>   BUILTIN\Administrators:(OI)(CI)(F)
>>>   BUILTIN\Users:(RX)
>>>   BUILTIN\Users:(OI)(CI)(IO)(GR,GE)
>>>   Everyone:(RX)
>>>   Everyone:(OI)(CI)(IO)(GR,GE)
>>>
>>> Successfully processed 1 files; Failed processing 0 files

>> Yes, I see now what you are saying. Didn't know why it behaves like that.
>> Do you reccomend:
>>
>> A. Noacl option  in fstab
>> B. Reinstall and leave icacls in windows alone so I can deploy in future
>> with runtime

> I decided to go with b. since windows ntfs wont recognize a and I want to
> deploy. I'm using cygwin to make agar gui apps for cobol (at least that is
> the plan).

That's normally the best way, although it may also be okay to add ACEs with
permission grants to groups as normal, or equivalents via GPOs.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Fwd: Objects in ACL cygwin win 10

[Jim McNamara via Cygwin]

I decided to go with b. since windows ntfs wont recognize a and I want to
deploy. Im using cygwin to make agar gui apps for cobol (at least that is
the plan). Thnx brian!

On Sat, Oct 24, 2020, 3:02 AM Jim McNamara 
wrote:

> Hi Brian
>
> Yes, I see now what you are saying. Didn't know why it behaves like that.
> Do you reccomend:
>
> A. Noacl option  in fstab
> B. Reinstall and leave icacls in windows alone so I can deploy in future
> with runtime
>
> Thnx,
> Roboloki
>
> On Sat, Oct 24, 2020, 12:46 AM Brian Inglis <
> brian.ing...@systematicsw.ab.ca> wrote:
>
>> On 2020-10-23 21:49, Jim McNamara via Cygwin wrote:
>> > On Fri, Oct 23, 2020, 10:06 PM Eliot Moss wrote:
>>
>> >> I have to admit I am not 100% sure what you are asking, but I am
>> careful
>> >> to grant SYSTEM access so
>> >> that my backup program can access and save a copy of virtually
>> everything
>>
>> > Thanks for you and Brian helping me.
>> > I used icacls cygwin /q /c /t reset
>>
>> You have to be very careful using icacls and other Windows commands with
>> Cygwin
>> ACLs as
>>
>> "ICACLS preserves the canonical ordering of ACE entries:
>> Explicit denials
>> Explicit grants
>> Inherited denials
>> Inherited grants"
>>
>> and Cygwin's POSIX ACLs may or may not obey this canonical order; Windows
>> File
>> Explorer often does not consider Cygwin ACLs in what it considers
>> canonical
>> order and requires them to be reordered, which breaks the Cygwin
>> permissions.
>>
>> Ah, that "NT AUTHORITY/SYSTEM" SID, normally paired with
>> BUILTIN/Administrators,
>> as users, groups, or both:
>>
>> $ ls -dl /proc/cygdrive/c/Users/; echo; getfacl /proc/cygdrive/c/Users/;
>> echo;
>> icacls C:/Users/
>> drwxr-xr-x+ 1 SYSTEM SYSTEM 0 Apr 13  2020 /proc/cygdrive/c/Users/
>>
>> # file: /proc/cygdrive/c/Users/
>> # owner: SYSTEM
>> # group: SYSTEM
>> user::rwx
>> group::r-x
>> group:Administrators:rwx#effective:r-x
>> group:Users:r-x
>> mask::r-x
>> other::r-x
>> default:user::rwx
>> default:group::---
>> default:group:Administrators:rwx#effective:r-x
>> default:group:Users:r-x
>> default:mask::r-x
>> default:other::r-x
>>
>> C:/Users/ NT AUTHORITY\SYSTEM:(OI)(CI)(F)
>>   BUILTIN\Administrators:(OI)(CI)(F)
>>   BUILTIN\Users:(RX)
>>   BUILTIN\Users:(OI)(CI)(IO)(GR,GE)
>>   Everyone:(RX)
>>   Everyone:(OI)(CI)(IO)(GR,GE)
>>
>> Successfully processed 1 files; Failed processing 0 files
>>
>> --
>> Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
>>
>> This email may be disturbing to some readers as it contains
>> too much technical detail. Reader discretion is advised.
>> [Data in binary units and prefixes, physical quantities in SI.]
>>
>> --
>> Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
>>
>> This email may be disturbing to some readers as it contains
>> too much technical detail. Reader discretion is advised.
>> [Data in binary units and prefixes, physical quantities in SI.]
>> --
>> Problem reports:  https://cygwin.com/problems.html
>> FAQ:  https://cygwin.com/faq/
>> Documentation:https://cygwin.com/docs.html
>> Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
>>
>
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Fwd: Objects in ACL cygwin win 10

[Jim McNamara via Cygwin]

Hi Brian

Yes, I see now what you are saying. Didn't know why it behaves like that.
Do you reccomend:

A. Noacl option  in fstab
B. Reinstall and leave icacls in windows alone so I can deploy in future
with runtime

Thnx,
Roboloki

On Sat, Oct 24, 2020, 12:46 AM Brian Inglis 
wrote:

> On 2020-10-23 21:49, Jim McNamara via Cygwin wrote:
> > On Fri, Oct 23, 2020, 10:06 PM Eliot Moss wrote:
>
> >> I have to admit I am not 100% sure what you are asking, but I am careful
> >> to grant SYSTEM access so
> >> that my backup program can access and save a copy of virtually
> everything
>
> > Thanks for you and Brian helping me.
> > I used icacls cygwin /q /c /t reset
>
> You have to be very careful using icacls and other Windows commands with
> Cygwin
> ACLs as
>
> "ICACLS preserves the canonical ordering of ACE entries:
> Explicit denials
> Explicit grants
> Inherited denials
> Inherited grants"
>
> and Cygwin's POSIX ACLs may or may not obey this canonical order; Windows
> File
> Explorer often does not consider Cygwin ACLs in what it considers canonical
> order and requires them to be reordered, which breaks the Cygwin
> permissions.
>
> Ah, that "NT AUTHORITY/SYSTEM" SID, normally paired with
> BUILTIN/Administrators,
> as users, groups, or both:
>
> $ ls -dl /proc/cygdrive/c/Users/; echo; getfacl /proc/cygdrive/c/Users/;
> echo;
> icacls C:/Users/
> drwxr-xr-x+ 1 SYSTEM SYSTEM 0 Apr 13  2020 /proc/cygdrive/c/Users/
>
> # file: /proc/cygdrive/c/Users/
> # owner: SYSTEM
> # group: SYSTEM
> user::rwx
> group::r-x
> group:Administrators:rwx#effective:r-x
> group:Users:r-x
> mask::r-x
> other::r-x
> default:user::rwx
> default:group::---
> default:group:Administrators:rwx#effective:r-x
> default:group:Users:r-x
> default:mask::r-x
> default:other::r-x
>
> C:/Users/ NT AUTHORITY\SYSTEM:(OI)(CI)(F)
>   BUILTIN\Administrators:(OI)(CI)(F)
>   BUILTIN\Users:(RX)
>   BUILTIN\Users:(OI)(CI)(IO)(GR,GE)
>   Everyone:(RX)
>   Everyone:(OI)(CI)(IO)(GR,GE)
>
> Successfully processed 1 files; Failed processing 0 files
>
> --
> Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
>
> This email may be disturbing to some readers as it contains
> too much technical detail. Reader discretion is advised.
> [Data in binary units and prefixes, physical quantities in SI.]
>
> --
> Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
>
> This email may be disturbing to some readers as it contains
> too much technical detail. Reader discretion is advised.
> [Data in binary units and prefixes, physical quantities in SI.]
> --
> Problem reports:  https://cygwin.com/problems.html
> FAQ:  https://cygwin.com/faq/
> Documentation:https://cygwin.com/docs.html
> Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
>
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Fwd: Objects in ACL cygwin win 10

[Brian Inglis]

On 2020-10-23 21:49, Jim McNamara via Cygwin wrote:
> On Fri, Oct 23, 2020, 10:06 PM Eliot Moss wrote:

>> I have to admit I am not 100% sure what you are asking, but I am careful
>> to grant SYSTEM access so
>> that my backup program can access and save a copy of virtually everything

> Thanks for you and Brian helping me.
> I used icacls cygwin /q /c /t reset

You have to be very careful using icacls and other Windows commands with Cygwin
ACLs as

"ICACLS preserves the canonical ordering of ACE entries:
Explicit denials
Explicit grants
Inherited denials
Inherited grants"

and Cygwin's POSIX ACLs may or may not obey this canonical order; Windows File
Explorer often does not consider Cygwin ACLs in what it considers canonical
order and requires them to be reordered, which breaks the Cygwin permissions.

Ah, that "NT AUTHORITY/SYSTEM" SID, normally paired with BUILTIN/Administrators,
as users, groups, or both:

$ ls -dl /proc/cygdrive/c/Users/; echo; getfacl /proc/cygdrive/c/Users/; echo;
icacls C:/Users/
drwxr-xr-x+ 1 SYSTEM SYSTEM 0 Apr 13  2020 /proc/cygdrive/c/Users/

# file: /proc/cygdrive/c/Users/
# owner: SYSTEM
# group: SYSTEM
user::rwx
group::r-x
group:Administrators:rwx#effective:r-x
group:Users:r-x
mask::r-x
other::r-x
default:user::rwx
default:group::---
default:group:Administrators:rwx#effective:r-x
default:group:Users:r-x
default:mask::r-x
default:other::r-x

C:/Users/ NT AUTHORITY\SYSTEM:(OI)(CI)(F)
  BUILTIN\Administrators:(OI)(CI)(F)
  BUILTIN\Users:(RX)
  BUILTIN\Users:(OI)(CI)(IO)(GR,GE)
  Everyone:(RX)
  Everyone:(OI)(CI)(IO)(GR,GE)

Successfully processed 1 files; Failed processing 0 files

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Fwd: Objects in ACL cygwin win 10

[Brian Inglis via Cygwin]

On 2020-10-23 21:49, Jim McNamara via Cygwin wrote:
> On Fri, Oct 23, 2020, 10:06 PM Eliot Moss wrote:

>> I have to admit I am not 100% sure what you are asking, but I am careful
>> to grant SYSTEM access so
>> that my backup program can access and save a copy of virtually everything

> Thanks for you and Brian helping me.
> I used icacls cygwin /q /c /t reset

You have to be very careful using icacls and other Windows commands with Cygwin
ACLs as

"ICACLS preserves the canonical ordering of ACE entries:
Explicit denials
Explicit grants
Inherited denials
Inherited grants"

and Cygwin's POSIX ACLs may or may not obey this canonical order; Windows File
Explorer often does not consider Cygwin ACLs in what it considers canonical
order and requires them to be reordered, which breaks the Cygwin permissions.

Ah, that "NT AUTHORITY/SYSTEM" SID, normally paired with BUILTIN/Administrators,
as users, groups, or both:

$ ls -dl /proc/cygdrive/c/Users/; echo; getfacl /proc/cygdrive/c/Users/; echo;
icacls C:/Users/
drwxr-xr-x+ 1 SYSTEM SYSTEM 0 Apr 13  2020 /proc/cygdrive/c/Users/

# file: /proc/cygdrive/c/Users/
# owner: SYSTEM
# group: SYSTEM
user::rwx
group::r-x
group:Administrators:rwx#effective:r-x
group:Users:r-x
mask::r-x
other::r-x
default:user::rwx
default:group::---
default:group:Administrators:rwx#effective:r-x
default:group:Users:r-x
default:mask::r-x
default:other::r-x

C:/Users/ NT AUTHORITY\SYSTEM:(OI)(CI)(F)
  BUILTIN\Administrators:(OI)(CI)(F)
  BUILTIN\Users:(RX)
  BUILTIN\Users:(OI)(CI)(IO)(GR,GE)
  Everyone:(RX)
  Everyone:(OI)(CI)(IO)(GR,GE)

Successfully processed 1 files; Failed processing 0 files

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Fwd: Objects in ACL cygwin win 10

[Jim McNamara via Cygwin]

-- Forwarded message >
Date: Fri, Oct 23, 2020, 11:48 PM
Subject: Re: Objects in ACL cygwin win 10
To: moss>


Hi elliot

Thanks for you and Brian helping me.

I used icacls cygwin /q /c /t reset

Thanks!
Roboloki

On Fri, Oct 23, 2020, 10:06 PM Eliot Moss  wrote:

> I have to admit I am not 100% sure what you are asking, but I am careful
> to grant SYSTEM access so
> that my backup program can access and save a copy of virtually everything
> ...
>
> EM
>
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Objects in ACL cygwin win 10

[Jim McNamara via Cygwin]

Hi all

I think I figured out that the processes that the ACL object/identifier
'system'  is referring to are like processes  in sysinternals process
explorer .

Not sure but that is my best guess.

If all else fails, I will chmod the hell out of everything until I beat
stat command into submission.

I will also be experimenting with your list of commands!

Have a cool weekend.

Thanks again for your help, Brian.

Later






On Fri, Oct 23, 2020, 6:41 PM Jim McNamara 
wrote:

> In more descriptive terms, an access control list is a list that
> determines which system processes or users are granted access to an object
> as well as what operations are permitted on the object.
>
> I tried to refer to the object 'system '. There are other objects like
> administrator, administrators, user, and everyone.
>
> Sorry, I tried to initially save keystrokes because I was typing on a
> phone keyboard.  Bad idea.
>
> Just wondering, for home users,  that aren't using domains, with ACLs,
> what type of objects are listed when you right click on a text file and
> choose properties and security in the windows 10 file explorer from within
> your cygwin install.
>
> I ask partially because with ACL as context, I cannot find a good example
> of 'system' object and what it is used for. I figure it must be either
> complicated or the opposite which is well understood .
>
> If you dont answer, I'm only frustrated with myself.
>
> Thanks for your help.
>
> Sorry Brian,
>
> Thanks,
> Roboloki
>
>
>
>
>
>
>
>
> On Fri, Oct 23, 2020, 5:31 PM Brian Inglis <
> brian.ing...@systematicsw.ab.ca> wrote:
>
>> On 2020-10-23 14:02, Jim McNamara via Cygwin wrote:
>> > I have : group everyone and my user sid as my ACLs with their
>> permissions
>> > in cygwin.  I use chmod to set permissions and dont use fstab.
>> >
>> > Can someone please check by right clicking properties security tab in
>> win
>> > 10 and verify that is all I need?
>> >
>> > I'm not using any domains.
>> >
>> > I'm not sure if I need system object that is used for OS things. I dont
>> > think so but am not sure.
>>
>> Not sure what you are asking about, but if you run
>>
>> $ ls -dl dir; getfacl dir; icacls dir
>> $ ls -dl dir/file; getfacl dir/file; icacls dir/file
>>
>> you can see how POSIX perms get translated into POSIX ACLs and
>> implemented as
>> Windows ACLs.
>>
>> If anything appears complex or inconsistent, try running setfacl -b on
>> dirs or
>> files then reapply chmod perms and recheck with the above.
>>
>> --
>> Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
>>
>> This email may be disturbing to some readers as it contains
>> too much technical detail. Reader discretion is advised.
>> [Data in binary units and prefixes, physical quantities in SI.]
>> --
>> Problem reports:  https://cygwin.com/problems.html
>> FAQ:  https://cygwin.com/faq/
>> Documentation:https://cygwin.com/docs.html
>> Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
>>
>
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Objects in ACL cygwin win 10

[Jim McNamara via Cygwin]

In more descriptive terms, an access control list is a list that determines
which system processes or users are granted access to an object as well as
what operations are permitted on the object.

I tried to refer to the object 'system '. There are other objects like
administrator, administrators, user, and everyone.

Sorry, I tried to initially save keystrokes because I was typing on a phone
keyboard.  Bad idea.

Just wondering, for home users,  that aren't using domains, with ACLs, what
type of objects are listed when you right click on a text file and choose
properties and security in the windows 10 file explorer from within your
cygwin install.

I ask partially because with ACL as context, I cannot find a good example
of 'system' object and what it is used for. I figure it must be either
complicated or the opposite which is well understood .

If you dont answer, I'm only frustrated with myself.

Thanks for your help.

Sorry Brian,

Thanks,
Roboloki








On Fri, Oct 23, 2020, 5:31 PM Brian Inglis 
wrote:

> On 2020-10-23 14:02, Jim McNamara via Cygwin wrote:
> > I have : group everyone and my user sid as my ACLs with their permissions
> > in cygwin.  I use chmod to set permissions and dont use fstab.
> >
> > Can someone please check by right clicking properties security tab in win
> > 10 and verify that is all I need?
> >
> > I'm not using any domains.
> >
> > I'm not sure if I need system object that is used for OS things. I dont
> > think so but am not sure.
>
> Not sure what you are asking about, but if you run
>
> $ ls -dl dir; getfacl dir; icacls dir
> $ ls -dl dir/file; getfacl dir/file; icacls dir/file
>
> you can see how POSIX perms get translated into POSIX ACLs and implemented
> as
> Windows ACLs.
>
> If anything appears complex or inconsistent, try running setfacl -b on
> dirs or
> files then reapply chmod perms and recheck with the above.
>
> --
> Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
>
> This email may be disturbing to some readers as it contains
> too much technical detail. Reader discretion is advised.
> [Data in binary units and prefixes, physical quantities in SI.]
> --
> Problem reports:  https://cygwin.com/problems.html
> FAQ:  https://cygwin.com/faq/
> Documentation:https://cygwin.com/docs.html
> Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
>
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Objects in ACL cygwin win 10

[Brian Inglis]

On 2020-10-23 14:02, Jim McNamara via Cygwin wrote:
> I have : group everyone and my user sid as my ACLs with their permissions
> in cygwin.  I use chmod to set permissions and dont use fstab.
> 
> Can someone please check by right clicking properties security tab in win
> 10 and verify that is all I need?
> 
> I'm not using any domains.
> 
> I'm not sure if I need system object that is used for OS things. I dont
> think so but am not sure.

Not sure what you are asking about, but if you run

$ ls -dl dir; getfacl dir; icacls dir
$ ls -dl dir/file; getfacl dir/file; icacls dir/file

you can see how POSIX perms get translated into POSIX ACLs and implemented as
Windows ACLs.

If anything appears complex or inconsistent, try running setfacl -b on dirs or
files then reapply chmod perms and recheck with the above.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Objects in ACL cygwin win 10

[Jim McNamara via Cygwin]

Hi all-

I have : group everyone and my user sid as my ACLs with their permissions
in cygwin.  I use chmod to set permissions and dont use fstab.

Can someone please check by right clicking properties security tab in win
10 and verify that is all I need?

I'm not using any domains.

I'm not sure if I need system object that is used for OS things. I dont
think so but am not sure.

Thanks
Roboloki
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Files and folders created with invalid ACL

[Eliot Moss]

On 6/22/2020 3:59 PM, Eliot Moss wrote:

On 6/22/2020 2:08 PM, Thorsten Kampe wrote:



Maybe you took Andre slightly literally; rephrasing, what are your current


Should have read "Andrey"!  Eliot
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Files and folders created with invalid ACL

[Brian Inglis]

On 2020-06-22 13:59, Eliot Moss wrote:
> On 6/22/2020 2:08 PM, Thorsten Kampe wrote:
>> * Andrey Repin (Mon, 22 Jun 2020 20:20:35 +0300)
>>>
>>>> icacls test.txt /verify
>>>> test.txt: Ace entries not in canonical order.
>>>
>>> This is normal. All conformant drivers MUST be able to correctly process 
>>> such
>>> ACL's. "Non-canonical" does not mean "invalid".
>>
>> `lsd` reports an error ("os error 1336"). But that might simply
>> be a result of the "non canonical order".
> 
> I agree; lsd seems to be being overly picky, not that you personally
> can do much about that.
> 
>>>> Interestingly the issue does not occur with files created in
>>>> the user's Cygwin home directory but - for instance - in the
>>>> Documents folder of the user's Windows profile.
>>>
>>>> This is a fresh Cygwin installation on a test system. Has
>>>> anyone found a solution?
>>>
>>>> [1]
> http://cygwin.1069669.n5.nabble.com/Issues-with-ACL-settings-after-updating-to-the-latest-cygwin-dll-td124123.html
> 
>>>
> 
>>> Needs more specifics.
>>> How did you set your fstab, particularly cygdrive prefix? Any extra mounts?
>>> How did you modify nsswitch?
>>
>> As I wrote, it's a "fresh Cygwin installation on a test
>> system" that means the phenomennon is observable directly after
>> the installation.
>>
>> I did some testing: files created in the user's home directory
>> (/home/Administrator), the home directory (/home) and other sub
>> directories don't show the issue.
>>
>> If I create a file or directory directly under / or anywhere
>> else on the drive, the issue occurs.
>>
>> If that would be the case on my main workstation, I would be
>> fine with that. Unfortunately on my main workstation the issue
>> occurs everywhere.
> 
> Maybe you took Andre slightly literally; rephrasing, what are your current
> fstab and nsswitch contents?  I would also ask, what do icacls and getfacl
> show on your / directory (the some that is the root of the hierarchy where
> things aren't working for you)?  It could be that fixing some entry there,
> and recursively, will get you to a good state.

Often setfacl -b on files may reduce the ACLs to simple canonical entries
u::rw[-x],g::r-[-x],o::r-[-x]

.\$USER:(F)
BUILTIN\$GROUP:(RX)
Everyone:(RX)

but you have to be careful that the same operation on directories keeps the
DACLs d:u::rwx,d:g::r-x,d:o::r-x

.\$USER:(F)
BUILTIN\$GROUP:(RX)
Everyone:(RX)
CREATOR OWNER:(OI)(CI)(IO)(F)
CREATOR GROUP:(OI)(CI)(IO)(RX)
Everyone:(OI)(CI)(IO)(RX)

as if the DACLs get stripped, files created under those directories often have
*NO* permissions: making them create only directories.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in IEC units and prefixes, physical quantities in SI.]
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Files and folders created with invalid ACL

[Eliot Moss]

On 6/22/2020 2:08 PM, Thorsten Kampe wrote:
> * Andrey Repin (Mon, 22 Jun 2020 20:20:35 +0300)
>>
>>> icacls test.txt /verify
>>> test.txt: Ace entries not in canonical order.
>>
>> This is normal. All conformant drivers MUST be able to correctly process such
>> ACL's. "Non-canonical" does not mean "invalid".
>
> `lsd` reports an error ("os error 1336"). But that might simply
> be a result of the "non canonical order".

I agree; lsd seems to be being overly picky, not that you personally
can do much about that.

>>> Interestingly the issue does not occur with files created in
>>> the user's Cygwin home directory but - for instance - in the
>>> Documents folder of the user's Windows profile.
>>
>>> This is a fresh Cygwin installation on a test system. Has
>>> anyone found a solution?
>>
>>> [1] 
http://cygwin.1069669.n5.nabble.com/Issues-with-ACL-settings-after-updating-to-the-latest-cygwin-dll-td124123.html

>>

>> Needs more specifics.
>> How did you set your fstab, particularly cygdrive prefix? Any extra mounts?
>> How did you modify nsswitch?
>
> As I wrote, it's a "fresh Cygwin installation on a test
> system" that means the phenomennon is observable directly after
> the installation.
>
> I did some testing: files created in the user's home directory
> (/home/Administrator), the home directory (/home) and other sub
> directories don't show the issue.
>
> If I create a file or directory directly under / or anywhere
> else on the drive, the issue occurs.
>
> If that would be the case on my main workstation, I would be
> fine with that. Unfortunately on my main workstation the issue
> occurs everywhere.

Maybe you took Andre slightly literally; rephrasing, what are your current
fstab and nsswitch contents?  I would also ask, what do icacls and getfacl
show on your / directory (the some that is the root of the hierarchy where
things aren't working for you)?  It could be that fixing some entry there,
and recursively, will get you to a good state.

Regards - Eliot Moss
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Files and folders created with invalid ACL

[Thorsten Kampe]

* Andrey Repin (Mon, 22 Jun 2020 20:20:35 +0300)
> 
> Greetings, Thorsten Kampe!
> 
> > I'm experiencing the issue described here[1]: files and folders
> > created with Cygwin utilities like touch and mkdir have an 
> > incorrect ACL ("The access control list (ACL) structure is 
> > invalid (os error 1336)").
> 
> > icacls test.txt /verify
> > test.txt: Ace entries not in canonical order.
> 
> This is normal. All conformant drivers MUST be able to correctly process such
> ACL's. "Non-canonical" does not mean "invalid".

`lsd` reports an error ("os error 1336"). But that might simply 
be a result of the "non canonical order".
 
> > Interestingly the issue does not occur with files created in 
> > the user's Cygwin home directory but - for instance - in the 
> > Documents folder of the user's Windows profile.
> 
> > This is a fresh Cygwin installation on a test system. Has 
> > anyone found a solution?
> 
> > [1] 
> > http://cygwin.1069669.n5.nabble.com/Issues-with-ACL-settings-after-updating-to-the-latest-cygwin-dll-td124123.html
> 
> Needs more specifics.
> How did you set your fstab, particularly cygdrive prefix? Any extra mounts?
> How did you modify nsswitch?

As I wrote, it's a "fresh Cygwin installation on a test 
system" that means the phenomennon is observable directly after 
the installation.

I did some testing: files created in the user's home directory 
(/home/Administrator), the home directory (/home) and other sub 
directories don't show the issue.

If I create a file or directory directly under / or anywhere 
else on the drive, the issue occurs.

If that would be the case on my main workstation, I would be 
fine with that. Unfortunately on my main workstation the issue 
occurs everywhere.

Thorsten

--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Files and folders created with invalid ACL

[Andrey Repin]

Greetings, Thorsten Kampe!

> I'm experiencing the issue described here[1]: files and folders
> created with Cygwin utilities like touch and mkdir have an 
> incorrect ACL ("The access control list (ACL) structure is 
> invalid (os error 1336)").

> icacls test.txt /verify
> test.txt: Ace entries not in canonical order.

This is normal. All conformant drivers MUST be able to correctly process such
ACL's. "Non-canonical" does not mean "invalid".

> Interestingly the issue does not occur with files created in 
> the user's Cygwin home directory but - for instance - in the 
> Documents folder of the user's Windows profile.

> This is a fresh Cygwin installation on a test system. Has 
> anyone found a solution?

> [1] 
> http://cygwin.1069669.n5.nabble.com/Issues-with-ACL-settings-after-updating-to-the-latest-cygwin-dll-td124123.html

Needs more specifics.
How did you set your fstab, particularly cygdrive prefix? Any extra mounts?
How did you modify nsswitch?


-- 
With best regards,
Andrey Repin
Monday, June 22, 2020 20:10:13

Sorry for my terrible english...

--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Files and folders created with invalid ACL

[Thorsten Kampe]

* Thorsten Kampe (Sun, 21 Jun 2020 20:42:55 +0200)
> 
> * Eliot Moss (Sun, 21 Jun 2020 14:10:21 -0400)
> > 
> > This is normal, and has to do with how Cygwin arranges to
> > model,
> > within the Windows ACL permissions system, some features of the
> > Posix permissions system. Don't "fix" the ACLs - that can make
> > the Posix functionality break.  While the entries are not in
> > canonical order, they work fine :-) ...
> 
> "The access control list (ACL) structure is invalid (os error 
> 1336". That's an error and not a cosmetic issue. Other tools 
> from the Unix world do not work fine with files that have an 
> invalid ACL: <https://github.com/Peltoche/lsd/issues/334
> #issuecomment-647119819>

I tried the noacl mount option: no change.

Thorsten

--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Files and folders created with invalid ACL

[Thorsten Kampe]

* Eliot Moss (Sun, 21 Jun 2020 14:10:21 -0400)
> 
> On 6/21/2020 1:56 PM, Thorsten Kampe wrote:
> > Hello,
> > 
> > I'm experiencing the issue described here[1]: files and folders
> > created with Cygwin utilities like touch and mkdir have an
> > incorrect ACL ("The access control list (ACL) structure is
> > invalid (os error 1336)").
> > 
> > icacls test.txt /verify
> > test.txt: Ace entries not in canonical order.
> > 
> > Interestingly the issue does not occur with files created in
> > the user's Cygwin home directory but - for instance - in the
> > Documents folder of the user's Windows profile.
> > 
> > This is a fresh Cygwin installation on a test system. Has
> > anyone found a solution?
> > 
> > [1] http://cygwin.1069669.n5.nabble.com/Issues-with-ACL-
> > settings-after-updating-to-the-latest-cygwin-dll-td124123.html
> 
> This is normal, and has to do with how Cygwin arranges to model,
> within the Windows ACL permissions system, some features of the
> Posix permissions system. Don't "fix" the ACLs - that can make
> the Posix functionality break.  While the entries are not in
> canonical order, they work fine :-) ...

"The access control list (ACL) structure is invalid (os error 
1336". That's an error and not a cosmetic issue. Other tools 
from the Unix world do not work fine with files that have an 
invalid ACL: <https://github.com/Peltoche/lsd/issues/334
#issuecomment-647119819>

Thorsten

--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Files and folders created with invalid ACL

[Eliot Moss]

On 6/21/2020 1:56 PM, Thorsten Kampe wrote:

Hello,

I'm experiencing the issue described here[1]: files and folders
created with Cygwin utilities like touch and mkdir have an
incorrect ACL ("The access control list (ACL) structure is
invalid (os error 1336)").

icacls test.txt /verify
test.txt: Ace entries not in canonical order.

Interestingly the issue does not occur with files created in
the user's Cygwin home directory but - for instance - in the
Documents folder of the user's Windows profile.

This is a fresh Cygwin installation on a test system. Has
anyone found a solution?

[1] http://cygwin.1069669.n5.nabble.com/Issues-with-ACL-
settings-after-updating-to-the-latest-cygwin-dll-td124123.html


This is normal, and has to do with how Cygwin arranges to model,
within the Windows ACL permissions system, some features of the
Posix permissions system. Don't "fix" the ACLs - that can make
the Posix functionality break.  While the entries are not in
canonical order, they work fine :-) ...

If you dig deeper into the Cygwin documentation on permissions
handling you can read all the gory details ...

Regards - Eliot Moss
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Files and folders created with invalid ACL

[Thorsten Kampe]

Hello,

I'm experiencing the issue described here[1]: files and folders 
created with Cygwin utilities like touch and mkdir have an 
incorrect ACL ("The access control list (ACL) structure is 
invalid (os error 1336)").

icacls test.txt /verify
test.txt: Ace entries not in canonical order.

Interestingly the issue does not occur with files created in 
the user's Cygwin home directory but - for instance - in the 
Documents folder of the user's Windows profile.

This is a fresh Cygwin installation on a test system. Has 
anyone found a solution?

[1] http://cygwin.1069669.n5.nabble.com/Issues-with-ACL-
settings-after-updating-to-the-latest-cygwin-dll-td124123.html

--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

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

--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

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

[Kacper Michajlow via Cygwin]

 > 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
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

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

--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

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

[Biswapriyo Nath via Cygwin]

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.
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"))
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

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

[Kacper Michajlow via Cygwin]

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  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
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Files created with CYGWIN have "NULL SID:(DENY)" windows ACL, inter alia

[Peter Binney]

On Sat, 28 Dec 2019 at 20:23, Lee  wrote:
>
> On 12/28/19, Andrey Repin  wrote:
> > Greetings, Peter Binney!
> >
> > Bottom posting in this list, please.
> >
> >> Hello Andrey - many thanks again.
> >
> >> I have added noacl to the default fstab entry, so it reads:
> >> none /cygdrive cygdrive noacl,binary,posix=0,user 0 0
> >
> >> and that sorts out the permissions problem, thank you.
> >
> >> But, bizarrely, it introduced a new one - the WHICH command no longer
> >> reports non-executable files on the PATH.
>
> Try adding the exec option to fstab:
>
> $ grep cygdrive /etc/fstab
> # none /cygdrive cygdrive binary,posix=0,user 0 0
> none /cygdrive cygdrive binary,posix=0,user,noacl,exec 0 0
>
> $ which xcopy
> /cygdrive/c/windows/system32/xcopy
>
> $ ls -l /cygdrive/c/windows/system32/xcopy
> -rwxr-xr-x 2 Lee None 47616 Sep 15  2018 
> /cygdrive/c/windows/system32/xcopy.exe
>
> Regards,
> Lee

Hi Lee - many thanks indeed for that. I've added "exec" and WHICH now works.

Cheers,
Peter

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Files created with CYGWIN have "NULL SID:(DENY)" windows ACL, inter alia

[Lee]

On 12/28/19, Andrey Repin  wrote:
> Greetings, Peter Binney!
>
> Bottom posting in this list, please.
>
>> Hello Andrey - many thanks again.
>
>> I have added noacl to the default fstab entry, so it reads:
>> none /cygdrive cygdrive noacl,binary,posix=0,user 0 0
>
>> and that sorts out the permissions problem, thank you.
>
>> But, bizarrely, it introduced a new one - the WHICH command no longer
>> reports non-executable files on the PATH.

Try adding the exec option to fstab:

$ grep cygdrive /etc/fstab
# none /cygdrive cygdrive binary,posix=0,user 0 0
none /cygdrive cygdrive binary,posix=0,user,noacl,exec 0 0

$ which xcopy
/cygdrive/c/windows/system32/xcopy

$ ls -l /cygdrive/c/windows/system32/xcopy
-rwxr-xr-x 2 Lee None 47616 Sep 15  2018 /cygdrive/c/windows/system32/xcopy.exe

Regards,
Lee

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Files created with CYGWIN have "NULL SID:(DENY)" windows ACL, inter alia

[Andrey Repin]

Greetings, Peter Binney!

Bottom posting in this list, please.

> Hello Andrey - many thanks again.

> I have added noacl to the default fstab entry, so it reads:
> none /cygdrive cygdrive noacl,binary,posix=0,user 0 0

> and that sorts out the permissions problem, thank you.

> But, bizarrely, it introduced a new one - the WHICH command no longer
> reports non-executable files on the PATH.

> Such files are found and executed OK (presumably because Windows logic
> is adhered to, where execute permission is not required), but WHICH
> doesn't "see" them.

> So I had to build a work-around for WHICH (which I use in various
> scriptware) since I can also find no way to set the execute bit on a
> file ("chmod a+x" doesn't seem to do anything with or without noacl).

This could be actually because you are lacking executable permission on your
files. Which Windows by default always set.


-- 
With best regards,
Andrey Repin
Saturday, December 28, 2019 16:57:49

Sorry for my terrible english...


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Files created with CYGWIN have "NULL SID:(DENY)" windows ACL, inter alia

[Peter Binney]

Hello Andrey - many thanks again.

I have added noacl to the default fstab entry, so it reads:
none /cygdrive cygdrive noacl,binary,posix=0,user 0 0

and that sorts out the permissions problem, thank you.

But, bizarrely, it introduced a new one - the WHICH command no longer
reports non-executable files on the PATH.

Such files are found and executed OK (presumably because Windows logic
is adhered to, where execute permission is not required), but WHICH
doesn't "see" them.

So I had to build a work-around for WHICH (which I use in various
scriptware) since I can also find no way to set the execute bit on a
file ("chmod a+x" doesn't seem to do anything with or without noacl).

Thanks again,
Peter


On Tue, 24 Dec 2019 at 09:20, Andrey Repin  wrote:
>
> Greetings, Peter Binney!
>
> > Hello Andrey - many thanks for that. I have now removed /etc/passwd
> > and /etc/group which didn't change anything.
>
> > I read some of your earlier posts on this and had already tried the noacl 
> > route.
>
> > Unfortunately it has made no difference. I added a second line to my
> > fstab so it read:
>
> > none /cygdrive cygdrive binary,posix=0,user 0 0
>
> Add "noacl" here.
>
> > e: /cygdrive/e ntfs noacl,binary,posix=0,user,auto 0 0
>
> Avoid overlapping mount points. The end result could be surprising.
>
> > with "mount" showing:
>
> > C:/cygwin/bin on /usr/bin type ntfs (binary,auto)
> > C:/cygwin/lib on /usr/lib type ntfs (binary,auto)
> > C:/cygwin on / type ntfs (binary,auto)
> > E: on /cygdrive/e type ntfs (binary,noacl,posix=0,user)
> > C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto)
> > D: on /cygdrive/d type ntfs (binary,posix=0,user,noumount,auto)
> > N: on /cygdrive/n type smbfs (binary,posix=0,user,noumount,auto)
> > P: on /cygdrive/p type smbfs (binary,posix=0,user,noumount,auto)
>
> > But when creating files on an E: I still get DENY for "NULL SID" and
> > other accounts.
>
> $ cat /etc/fstab && mount
> # For a description of the file format, see the Users Guide
> # http://cygwin.com/cygwin-ug-net/using.html#mount-table
>
> # This is default anyway:
> #none /cygdrive cygdrive binary,posix=0,user 0 0
> none / cygdrive noacl,binary,nouser,posix=0 0 0
> W:/ /var/run ntfs acl,binary,nouser,posix=0 0 0
> C:/Users /home bind noacl,binary,exec,posix=0 0 0
> none /tmp usertemp binary,nouser,posix=1 0 0
>
> C:/Users/ANRDAE~1/AppData/Local/Temp on /tmp type ntfs (binary,usertemp)
> C:/Programs/Cygwin_64/bin on /usr/bin type ntfs (binary,auto)
> C:/Programs/Cygwin_64/lib on /usr/lib type ntfs (binary,auto)
> C:/Programs/Cygwin_64 on / type ntfs (binary,auto)
> C:/Users on /home type ntfs (binary,exec,noacl,posix=0)
> W: on /var/run type ntfs (binary,posix=0)
> C: on /c type ntfs (binary,noacl,posix=0,noumount,auto)
> M: on /m type vfat (binary,noacl,posix=0,noumount,auto)
> Y: on /y type smbfs (binary,noacl,posix=0,noumount,auto)
> Z: on /z type smbfs (binary,noacl,posix=0,noumount,auto)
>
>
> --
> With best regards,
> Andrey Repin
> Tuesday, December 24, 2019 12:14:33
>
> Sorry for my terrible english...
>

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Files created with CYGWIN have "NULL SID:(DENY)" windows ACL, inter alia

[Andrey Repin]

Greetings, Peter Binney!

> Hello Andrey - many thanks for that. I have now removed /etc/passwd
> and /etc/group which didn't change anything.

> I read some of your earlier posts on this and had already tried the noacl 
> route.

> Unfortunately it has made no difference. I added a second line to my
> fstab so it read:

> none /cygdrive cygdrive binary,posix=0,user 0 0

Add "noacl" here.

> e: /cygdrive/e ntfs noacl,binary,posix=0,user,auto 0 0

Avoid overlapping mount points. The end result could be surprising.

> with "mount" showing:

> C:/cygwin/bin on /usr/bin type ntfs (binary,auto)
> C:/cygwin/lib on /usr/lib type ntfs (binary,auto)
> C:/cygwin on / type ntfs (binary,auto)
> E: on /cygdrive/e type ntfs (binary,noacl,posix=0,user)
> C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto)
> D: on /cygdrive/d type ntfs (binary,posix=0,user,noumount,auto)
> N: on /cygdrive/n type smbfs (binary,posix=0,user,noumount,auto)
> P: on /cygdrive/p type smbfs (binary,posix=0,user,noumount,auto)

> But when creating files on an E: I still get DENY for "NULL SID" and
> other accounts.

$ cat /etc/fstab && mount
# For a description of the file format, see the Users Guide
# http://cygwin.com/cygwin-ug-net/using.html#mount-table

# This is default anyway:
#none /cygdrive cygdrive binary,posix=0,user 0 0
none / cygdrive noacl,binary,nouser,posix=0 0 0
W:/ /var/run ntfs acl,binary,nouser,posix=0 0 0
C:/Users /home bind noacl,binary,exec,posix=0 0 0
none /tmp usertemp binary,nouser,posix=1 0 0

C:/Users/ANRDAE~1/AppData/Local/Temp on /tmp type ntfs (binary,usertemp)
C:/Programs/Cygwin_64/bin on /usr/bin type ntfs (binary,auto)
C:/Programs/Cygwin_64/lib on /usr/lib type ntfs (binary,auto)
C:/Programs/Cygwin_64 on / type ntfs (binary,auto)
C:/Users on /home type ntfs (binary,exec,noacl,posix=0)
W: on /var/run type ntfs (binary,posix=0)
C: on /c type ntfs (binary,noacl,posix=0,noumount,auto)
M: on /m type vfat (binary,noacl,posix=0,noumount,auto)
Y: on /y type smbfs (binary,noacl,posix=0,noumount,auto)
Z: on /z type smbfs (binary,noacl,posix=0,noumount,auto)


-- 
With best regards,
Andrey Repin
Tuesday, December 24, 2019 12:14:33

Sorry for my terrible english...


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Files created with CYGWIN have "NULL SID:(DENY)" windows ACL, inter alia

[Peter Binney]

Hello Andrey - many thanks for that. I have now removed /etc/passwd
and /etc/group which didn't change anything.

I read some of your earlier posts on this and had already tried the noacl route.

Unfortunately it has made no difference. I added a second line to my
fstab so it read:

none /cygdrive cygdrive binary,posix=0,user 0 0
e: /cygdrive/e ntfs noacl,binary,posix=0,user,auto 0 0

with "mount" showing:

C:/cygwin/bin on /usr/bin type ntfs (binary,auto)
C:/cygwin/lib on /usr/lib type ntfs (binary,auto)
C:/cygwin on / type ntfs (binary,auto)
E: on /cygdrive/e type ntfs (binary,noacl,posix=0,user)
C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto)
D: on /cygdrive/d type ntfs (binary,posix=0,user,noumount,auto)
N: on /cygdrive/n type smbfs (binary,posix=0,user,noumount,auto)
P: on /cygdrive/p type smbfs (binary,posix=0,user,noumount,auto)

But when creating files on an E: I still get DENY for "NULL SID" and
other accounts.




On Sun, 22 Dec 2019 at 14:05, Andrey Repin  wrote:
>
> Greetings, Peter Binney!
>
> > Creating a file using "> newfile", "icacls newfile" shows various DENY 
> > settings:
>
> > newfile NULL SID:(DENY)(Rc,S,WEA,X,DC)
> > JCPR-DELL-3\peter:(R,W,D,WDAC,WO)
> > NT AUTHORITY\SYSTEM:(DENY)(S,X)
> > BUILTIN\Administrators:(DENY)(S,X)
> > BUILTIN\Users:(DENY)(S,X)
> > JCPR-DELL-3\None:(R)
> > NT AUTHORITY\SYSTEM:(RX,W)
> > BUILTIN\Administrators:(RX,W)
> > BUILTIN\Users:(RX,W)
> > Everyone:(R)
>
> > Whereas on a file created from Windows Explorer I see:
> > New Text Document.txt BUILTIN\Users:(I)(M)
> >   Everyone:(I)(RX)
> >   JCPR-DELL-3\peter:(I)(F)
> >   BUILTIN\Administrators:(I)(F)
> >   NT AUTHORITY\SYSTEM:(I)(F)
>
> > "mkpasswd" and "mkgroup"
>
> Please use getent
>
> > both show I (user "peter") have expected
> > entries in /etc/passwd and /etc/group (I attach both)
>
> Delete both from your system, they are not needed, except for extremely rare
> cases.
>
> > Running "whoami" commands from powershell shows:
>
> > PS E:\temp> whoami /groups
>
> > GROUP INFORMATION
> > -
> > Group NameType
> > SID  Attributes
> > =
> >  
> > ==
> > Everyone
> > Well-known group S-1-1-0  Mandatory group, Enabled by default,
> > Enabled group
> > NT AUTHORITY\Local account and member of Administrators group
> > Well-known group S-1-5-114Group used for deny only
> > BUILTIN\AdministratorsAlias
> > S-1-5-32-544 Group used for deny only
> > BUILTIN\Performance Log Users Alias
> > S-1-5-32-559 Mandatory group, Enabled by default, Enabled
> > group
> > BUILTIN\Users Alias
> > S-1-5-32-545 Mandatory group, Enabled by default, Enabled
> > group
> > NT AUTHORITY\INTERACTIVE
> > Well-known group S-1-5-4  Mandatory group, Enabled by default,
> > Enabled group
> > CONSOLE LOGON
> > Well-known group S-1-2-1  Mandatory group, Enabled by default,
> > Enabled group
> > NT AUTHORITY\Authenticated Users
> > Well-known group S-1-5-11 Mandatory group, Enabled by default,
> > Enabled group
> > NT AUTHORITY\This Organization
> > Well-known group S-1-5-15 Mandatory group, Enabled by default,
> > Enabled group
> > NT AUTHORITY\Local account
> > Well-known group S-1-5-113Mandatory group, Enabled by default,
> > Enabled group
> > LOCAL
> > Well-known group S-1-2-0  Mandatory group, Enabled by default,
> > Enabled group
> > NT AUTHORITY\NTLM Authentication
> > Well-known group S-1-5-64-10  Mandatory group, Enabled by default,
> > Enabled group
> > Mandatory Label\Medium Mandatory LevelLabel
> > S-1-16-8192
> > PS E:\temp> whoami
> > jcpr-dell-3\peter
> > PS E:\temp> whoami /user
>
> > USER INFORMATION
> > 
> > User Name SID
> > = =
> > jcpr-dell-3\peter S-1-5-21-1468824806-2062748802-729869357-100
>
> > I also attach cygcheck.out
>
> See my earlier message, I strongly suggest "noacl" mount option for
> directories outside Cygwin root.
> No windows program expects stupid access restrictions produces by basic POSIX
> permissions.
>
>
> --
> With best regards,
> Andrey Repin
> Sunday, December 22, 2019 15:35:08
>
> Sorry for my terrible english...
>

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Files created with CYGWIN have "NULL SID:(DENY)" windows ACL, inter alia

[Andrey Repin]

Greetings, Peter Binney!

> Creating a file using "> newfile", "icacls newfile" shows various DENY 
> settings:

> newfile NULL SID:(DENY)(Rc,S,WEA,X,DC)
> JCPR-DELL-3\peter:(R,W,D,WDAC,WO)
> NT AUTHORITY\SYSTEM:(DENY)(S,X)
> BUILTIN\Administrators:(DENY)(S,X)
> BUILTIN\Users:(DENY)(S,X)
> JCPR-DELL-3\None:(R)
> NT AUTHORITY\SYSTEM:(RX,W)
> BUILTIN\Administrators:(RX,W)
> BUILTIN\Users:(RX,W)
> Everyone:(R)

> Whereas on a file created from Windows Explorer I see:
> New Text Document.txt BUILTIN\Users:(I)(M)
>   Everyone:(I)(RX)
>   JCPR-DELL-3\peter:(I)(F)
>   BUILTIN\Administrators:(I)(F)
>   NT AUTHORITY\SYSTEM:(I)(F)

> "mkpasswd" and "mkgroup"

Please use getent

> both show I (user "peter") have expected
> entries in /etc/passwd and /etc/group (I attach both)

Delete both from your system, they are not needed, except for extremely rare
cases.

> Running "whoami" commands from powershell shows:

> PS E:\temp> whoami /groups

> GROUP INFORMATION
> -
> Group NameType
> SID  Attributes
> =
>  
> ==
> Everyone
> Well-known group S-1-1-0  Mandatory group, Enabled by default,
> Enabled group
> NT AUTHORITY\Local account and member of Administrators group
> Well-known group S-1-5-114Group used for deny only
> BUILTIN\AdministratorsAlias
> S-1-5-32-544 Group used for deny only
> BUILTIN\Performance Log Users Alias
> S-1-5-32-559 Mandatory group, Enabled by default, Enabled
> group
> BUILTIN\Users Alias
> S-1-5-32-545 Mandatory group, Enabled by default, Enabled
> group
> NT AUTHORITY\INTERACTIVE
> Well-known group S-1-5-4  Mandatory group, Enabled by default,
> Enabled group
> CONSOLE LOGON
> Well-known group S-1-2-1  Mandatory group, Enabled by default,
> Enabled group
> NT AUTHORITY\Authenticated Users
> Well-known group S-1-5-11 Mandatory group, Enabled by default,
> Enabled group
> NT AUTHORITY\This Organization
> Well-known group S-1-5-15 Mandatory group, Enabled by default,
> Enabled group
> NT AUTHORITY\Local account
> Well-known group S-1-5-113Mandatory group, Enabled by default,
> Enabled group
> LOCAL
> Well-known group S-1-2-0  Mandatory group, Enabled by default,
> Enabled group
> NT AUTHORITY\NTLM Authentication
> Well-known group S-1-5-64-10  Mandatory group, Enabled by default,
> Enabled group
> Mandatory Label\Medium Mandatory LevelLabel
> S-1-16-8192
> PS E:\temp> whoami
> jcpr-dell-3\peter
> PS E:\temp> whoami /user

> USER INFORMATION
> 
> User Name SID
> = =
> jcpr-dell-3\peter S-1-5-21-1468824806-2062748802-729869357-100

> I also attach cygcheck.out

See my earlier message, I strongly suggest "noacl" mount option for
directories outside Cygwin root.
No windows program expects stupid access restrictions produces by basic POSIX
permissions.


-- 
With best regards,
Andrey Repin
Sunday, December 22, 2019 15:35:08

Sorry for my terrible english...


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Files created with CYGWIN have "NULL SID:(DENY)" windows ACL, inter alia

[Eliot Moss]

Yes, if you read the part in the user's guide about ACLs it explains that.
As I recall, it's a place to hang information that is otherwise hard to
represent in Windows, because of the differences between how the Windows
and Posix permissions systems work.  You'll also find that the ACLs are
not in the order that Windows likes.  Don't let Windows reorder them, or
you will break what Cygwin is trying to accomplish!  Even though the
order is not standard, the ACLs work ...

Eliot Moss

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Files created with CYGWIN have "NULL SID:(DENY)" windows ACL, inter alia

[Peter Binney]

Creating a file using "> newfile", "icacls newfile" shows various DENY settings:

newfile NULL SID:(DENY)(Rc,S,WEA,X,DC)
JCPR-DELL-3\peter:(R,W,D,WDAC,WO)
NT AUTHORITY\SYSTEM:(DENY)(S,X)
BUILTIN\Administrators:(DENY)(S,X)
BUILTIN\Users:(DENY)(S,X)
JCPR-DELL-3\None:(R)
NT AUTHORITY\SYSTEM:(RX,W)
BUILTIN\Administrators:(RX,W)
BUILTIN\Users:(RX,W)
Everyone:(R)

Whereas on a file created from Windows Explorer I see:
New Text Document.txt BUILTIN\Users:(I)(M)
  Everyone:(I)(RX)
  JCPR-DELL-3\peter:(I)(F)
  BUILTIN\Administrators:(I)(F)
  NT AUTHORITY\SYSTEM:(I)(F)

"mkpasswd" and "mkgroup" both show I (user "peter") have expected
entries in /etc/passwd and /etc/group (I attach both)

Running "whoami" commands from powershell shows:

PS E:\temp> whoami /groups

GROUP INFORMATION
-
Group NameType
SID  Attributes
=
 
==
Everyone
Well-known group S-1-1-0  Mandatory group, Enabled by default,
Enabled group
NT AUTHORITY\Local account and member of Administrators group
Well-known group S-1-5-114Group used for deny only
BUILTIN\AdministratorsAlias
S-1-5-32-544 Group used for deny only
BUILTIN\Performance Log Users Alias
S-1-5-32-559 Mandatory group, Enabled by default, Enabled
group
BUILTIN\Users Alias
S-1-5-32-545 Mandatory group, Enabled by default, Enabled
group
NT AUTHORITY\INTERACTIVE
Well-known group S-1-5-4  Mandatory group, Enabled by default,
Enabled group
CONSOLE LOGON
Well-known group S-1-2-1  Mandatory group, Enabled by default,
Enabled group
NT AUTHORITY\Authenticated Users
Well-known group S-1-5-11 Mandatory group, Enabled by default,
Enabled group
NT AUTHORITY\This Organization
Well-known group S-1-5-15 Mandatory group, Enabled by default,
Enabled group
NT AUTHORITY\Local account
Well-known group S-1-5-113Mandatory group, Enabled by default,
Enabled group
LOCAL
Well-known group S-1-2-0  Mandatory group, Enabled by default,
Enabled group
NT AUTHORITY\NTLM Authentication
Well-known group S-1-5-64-10  Mandatory group, Enabled by default,
Enabled group
Mandatory Label\Medium Mandatory LevelLabel
S-1-16-8192
PS E:\temp> whoami
jcpr-dell-3\peter
PS E:\temp> whoami /user

USER INFORMATION

User Name SID
= =
jcpr-dell-3\peter S-1-5-21-1468824806-2062748802-729869357-100

I also attach cygcheck.out


group
Description: Binary data


passwd
Description: Binary data


cygcheck.out
Description: Binary data

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

how do i create a trusted-installer? (was Re: Trying to create default ACL entries to match file ACL entries)

[L A Walsh]

On 2019/06/04 14:34, Chris Wagner wrote:
> Hi Linda, / is just a mount to something like C:\Cygwin64 so there is no 
> problem in changing it.
>   

Uh...about thatoh my system '/' points to 'C:\'.  Isn't life fun!

I think I finally got it.  I broke down and used "icacls" for fine tuning
and now seem to have:
\ NT SERVICE\TrustedInstaller:(F)
  NT SERVICE\TrustedInstaller:(OI)(CI)(F)
  Bliss\law:(OI)(CI)(F)
  BLISS\lawgroup:(OI)(CI)(F)
  BLISS\Domain Admins:(OI)(CI)(F)
  BLISS\Domain Users:(OI)(CI)(RX)
  BUILTIN\Administrators:(OI)(CI)(F)
  NT AUTHORITY\SYSTEM:(OI)(CI)(F)
  BUILTIN\Users:(OI)(CI)(RX)
  Mandatory Label\High Mandatory Level:(OI)(CI)(NW)


FWIW, BTW, I have two scripts (one in perl, one in shell) that convert
from a SID<->a hex value as you might see in the registry, and back
again.  As much as I've been able to test they seem correct. and agree
with other tools of the same
ilk.  You probably have your own, but if not, they are fairly trivial
and being in either shell or perl they aren't too difficult to understand.

If there is a want, I can just post them here, neither is very long.
> wc sidhex_xlate.{pl,sh}
 127  422 3067 sidhex_xlate.pl
 193  566 4697 sidhex_xlate.sh
 320  988 7764 total

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Trying to create default ACL entries to match file ACL entries

[Brian Inglis]

On 2019-06-04 15:34, Chris Wagner wrote:
> / is just a mount to something like C:\Cygwin64 so there is no problem
> in changing it.
> You should delete all the target thing's permissions first to guarantee 
> starting
> from a clean slate.
> $ setfacl -kb z2/ && getfacl z1/ |setfacl -f - z2/
> This works for me with the latest packages.

Watch out for valid DACLs if you want to be able to create files in any
subdirectory from Windows programs or access them after creation: thar be
grumblins!

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Trying to create default ACL entries to match file ACL entries

[L A Walsh]

On 2019/06/04 14:26, Brian Inglis wrote:
> On 2019-06-04 13:59, L A Walsh wrote:
>   
>> lets see if this is more clear:
>> On 2019/06/04 12:44, Eliot Moss wrote:
>> 
>>> On 6/4/2019 3:34 PM, L A Walsh wrote:
>>>   
>>>> I am trying to create an entry for '/' (or '.' w/me sitting in '/')
>>>> where the default entries are the same as the file entries.
>>>>   ^^^
>>>> so tried doing:
>>>>getfacl . | setfacl -d - .
>>>> 
>> Sorry, but am trying to get the 'file' entries (w/o the -d)
>> copied into the default.
>> 
>
> Not seeing -d, --default documented or supported in the code as an option flag
> under Cygwin: it is available under Debian/Ubuntu at least, and probably other
> Linux; 
Not to confuse things, but its under getfacl.

silly me, thinking setfacl might have the same flag
very confusing...
So need to getfacl to get access perms, then turn them into a form for
default acl...
Sigh...


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Trying to create default ACL entries to match file ACL entries

[Chris Wagner]

Hi Linda, / is just a mount to something like C:\Cygwin64 so there is no 
problem in changing it.


You should delete all the target thing's permissions first to guarantee 
starting from a clean slate.


$ setfacl -kb z2/ && getfacl z1/ |setfacl -f - z2/

This works for me with the latest packages.

HTH, Chris



--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Trying to create default ACL entries to match file ACL entries

[Brian Inglis]

On 2019-06-04 13:59, L A Walsh wrote:
> lets see if this is more clear:
> On 2019/06/04 12:44, Eliot Moss wrote:
>> On 6/4/2019 3:34 PM, L A Walsh wrote:
>>> I am trying to create an entry for '/' (or '.' w/me sitting in '/')
>>> where the default entries are the same as the file entries.
>>>   ^^^
>>> so tried doing:
>>>getfacl . | setfacl -d - .
> Sorry, but am trying to get the 'file' entries (w/o the -d)
> copied into the default.

Not seeing -d, --default documented or supported in the code as an option flag
under Cygwin: it is available under Debian/Ubuntu at least, and probably other
Linux; neither are the file input option flags -M, --modify-file, -X,
--remove-file, or symbolic link -L, --logical, -P, --physical, or -R,
--recursive option flags.

Cygwin equivalent based on setfacl(1) would be something like:
$ getfacl -a source_file | sed 's/.*/&\nd:&/' | setfacl -f - target_file
where you are getting and duplicating the file accesses and also creating the
DACLs.

> On 2019/06/04 12:44, Eliot Moss wrote:
>> O ... not sure _I'd_ mess what / on a Windows system!
> -
> Ya, not idea, but too late for that.  Thanks for your
> vote of confidence though!  :wa: :-(

I have had success using only setfacl -m and specifying everything I want
changed or set in that argument e.g.

$ setfacl -m u::rwx,g::r-x,o::r-x,d:u::rwx,d:g::r-x,d:o::r-x /

probably using an admin account running with elevated permissions in this case.

For Cygwin root /, I have only:

$ lsp / | cygcheck-hrsv.sed
drwxr-xr-x+ 1 $USER Administrators 0 May 31 05:19 /
# file: /
# owner: $USER
# group: Administrators
user::rwx
group::r-x
other::r-x
default:user::rwx
default:group::r-x
default:other::r-x

C:/.../cygwin64 $HOSTNAME\$USER:(F)
  BUILTIN\Administrators:(RX)
  Everyone:(RX)
  CREATOR OWNER:(OI)(CI)(IO)(F)
  CREATOR GROUP:(OI)(CI)(IO)(RX)
  Everyone:(OI)(CI)(IO)(RX)

Successfully processed 1 files; Failed processing 0 files

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Trying to create default ACL entries to match file ACL entries

[L A Walsh]

lets see if this is more clear:


On 2019/06/04 12:44, Eliot Moss wrote:
> On 6/4/2019 3:34 PM, L A Walsh wrote:
>   
>> I am trying to create an entry for '/' (or '.' w/me sitting in '/')
>> where the default entries are the same as the file entries.
>>   ^^^
>>
>> so tried doing:
>>
>>getfacl . | setfacl -d - .
>> 
Sorry, but am trying to get the 'file' entries (w/o the -d)
copied into the default.

On 2019/06/04 12:44, Eliot Moss wrote:
> O ... not sure _I'd_ mess what / on a Windows system!
>   
-
Ya, not idea, but too late for that.  Thanks for your
vote of confidence though!  :wa: :-(



--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Trying to create default ACL entries to match file ACL entries

[Eliot Moss]

On 6/4/2019 3:34 PM, L A Walsh wrote:

I am trying to create an entry for '/' (or '.' w/me sitting in '/')
where the default entries are the same as the file entries.


O ... not sure _I'd_ mess what / on a Windows system!


I noticed the example give in the manpage for copying entries:

The special filename "-" indicates reading from stdin.
Note that you can use this with getfacl and setfacl to copy ACLs from
one file to another:

$ getfacl source_file | setfacl -f - target_file

so tried doing:

   getfacl . | setfacl -d - .


I have no problem doing:

mkdir temp
getfacl . | setfacl -f - temp
getfacl temp | setfacl -f .
getfacl / | setfacl -f .

I didn't want to try setting things on /, but
you might:

cd /
mkdir foo
getfacl foo | setfacl -f - .

But I am not sure what foo would have as its permission, i.e., whether
they are what you want.

Regards - EM

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Trying to create default ACL entries to match file ACL entries

[L A Walsh]

I am trying to create an entry for '/' (or '.' w/me sitting in '/')
where the default entries are the same as the file entries.

I noticed the example give in the manpage for copying entries:

The special filename "-" indicates reading from stdin.
   Note that you can use this with getfacl and setfacl to copy ACLs from
   one file to another:

   $ getfacl source_file | setfacl -f - target_file

so tried doing:

  getfacl . | setfacl -d - .


But keep running into:

  setfacl: missing entries.

Also tried writing to a file and modifying that.
Last try had:

# file: .
# owner: Bliss\law
# group: Bliss\lawgroup
default:user:Bliss\law:rwx
default:group:SYSTEM:rwx
default:group:Bliss\lawgroup:rwx
default:group:Bliss\Domain Admins:rwx
default:group:Bliss\Domain Users:r-x
default:group:Administrators:rwx
default:other::r-x
mask::rwx
user::rwx
group::rwx
other::r-x

But still with:
  /> setfacl -f /tmp/norm .
got:
  setfacl: missing entries.

Using it with '-d' just gave illegal acl entries, so
that didn't work either.

What am I missing?  Thanks!
-linda



--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: continued acl problems

[Andrey Repin]

Greetings, L A Walsh!

>>> In all of these cases it appears that the problem is with directories.
>> 
>>> At first thought it was related to presence of 'TRUSTED USER'
>> 
>>> But I saw some 'flakeyness' on domain ID's,
>>> where I saw it display the correct text for them,
>>> but scrolling down to look for problems, and back up had the
>>> permissions dialog showing the raw numbers for my domain ID's, but
>>> scrolling again showed them as Domain\ID.
>> 
>> Do you have cygserver running?
> 
> Wellrt now, not sure...hmmm

If you see them in service manager, then I'm curious by your observed
behavior.
cygserver's one effect is to stabilize SID resolution within a session.
And yes, you should not be starting cygserver manually, unless for testing
purposes. I have no idea, what effect would have multiple cygserver's running
in the same system.

> I should have had it running, as it's part of my startXwin.sh
> script which I run manually at start of every session, but
> did an update and had to kill off most or all of the cygstuff.

> But restarted 'X', which used to -- should have restarted
> it but, looking didn't see it in process list and trying the
> same command manually gave an error:


>> cygrunsrv -n -O -S -d messagebus cygserver
> cygrunsrv: --neverexits is only allowed with --install

> So I look at help and install is for installing a new service

> So I look at what services are installed:

>> cygrunsrv.exe -L
> cygserver
> messagebus
> syslogd

> Looks like the cygserver is already installed...

> Looking in the services control panel, I see cygserver, 
> messagebus and syslogd, but syslogd won't stay running.

> Since I just ran the cygrunsrv command above, not sure if that
> started it or not. 

> If I specify two services on the command line, should it
> have started both? with the same 'cygrunsrv'?  They are set
> to start on system boot, but after the cyg-upgrade, they were 
> likely killed and restarting 'X' likely didn't restart anything
> because of the error.  

> Because cygserver won't let you start syslogd unless stderr 
> isn't a TTY, I have to send cygserver's error off to /dev/null,
> so I wouldn't have seen any errors.  

> So...am guessing it wasn't running, but may be now (not sure
> why syslogd isn't running -- will have to check that out later.

> But for now, will have to see if this reoccurs 

> Thanks for the possible cause! ;-)


-- 
With best regards,
Andrey Repin
Saturday, September 8, 2018 3:23:39

Sorry for my terrible english...


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: continued acl problems

[L A Walsh]

On 9/7/2018 2:26 PM, Andrey Repin wrote:

Greetings, L A Walsh!


In all of these cases it appears that the problem is with directories.



At first thought it was related to presence of 'TRUSTED USER'



But I saw some 'flakeyness' on domain ID's,
where I saw it display the correct text for them,
but scrolling down to look for problems, and back up had the
permissions dialog showing the raw numbers for my domain ID's, but
scrolling again showed them as Domain\ID.


Do you have cygserver running?


Wellrt now, not sure...hmmm
I should have had it running, as it's part of my startXwin.sh
script which I run manually at start of every session, but
did an update and had to kill off most or all of the cygstuff.

But restarted 'X', which used to -- should have restarted
it but, looking didn't see it in process list and trying the
same command manually gave an error:



cygrunsrv -n -O -S -d messagebus cygserver

cygrunsrv: --neverexits is only allowed with --install

So I look at help and install is for installing a new service

So I look at what services are installed:


cygrunsrv.exe -L

cygserver
messagebus
syslogd

Looks like the cygserver is already installed...

Looking in the services control panel, I see cygserver, 
messagebus and syslogd, but syslogd won't stay running.


Since I just ran the cygrunsrv command above, not sure if that
started it or not. 


If I specify two services on the command line, should it
have started both? with the same 'cygrunsrv'?  They are set
to start on system boot, but after the cyg-upgrade, they were 
likely killed and restarting 'X' likely didn't restart anything
because of the error.  

Because cygserver won't let you start syslogd unless stderr 
isn't a TTY, I have to send cygserver's error off to /dev/null,
so I wouldn't have seen any errors.  


So...am guessing it wasn't running, but may be now (not sure
why syslogd isn't running -- will have to check that out later.

But for now, will have to see if this reoccurs 

Thanks for the possible cause! ;-)

Gotta love SW!

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: continued acl problems

[Andrey Repin]

Greetings, L A Walsh!

> In all of these cases it appears that the problem is with directories.

> At first thought it was related to presence of 'TRUSTED USER'

> But I saw some 'flakeyness' on domain ID's,
> where I saw it display the correct text for them,
> but scrolling down to look for problems, and back up had the
> permissions dialog showing the raw numbers for my domain ID's, but
> scrolling again showed them as Domain\ID.

Do you have cygserver running?

> So that's something to consider -- if there is a momentary flake
> in the resolution, it might cause a probjust tried those files
> again. the "tmp/05" and "tmp/51..."

> No errors.

> Did something else change besides these probs you looked at?

> I have to stress...I've never seen the Cannot_acl_to_text
> message before my reporting it a week or so ago

> saw instances in use of 'tar' and 'rsync' at this point.

> I have seen similar messages out of rsync copying from a windows
> dir to a samba dir -- I figured local ID didn't exist on the
> remote samba dir.


> But have never seen it going between win-directories on the same
> machine...that's the new "problem", with current symptoms seeming
> to be limited to directories (maybe due to 2 acls)...

> Have never had these msgs going from win<->win on same
> machine.


-- 
With best regards,
Andrey Repin
Saturday, September 8, 2018 0:25:37

Sorry for my terrible english...


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

continued acl problems

[L A Walsh]

I'm now getting errors where I never got errors before --
this may be for the 'Trusted installer' user, or possibly
domain users that I

I tried copying files using tar|tar...I have a script
that I've tried to run daily (but only do it manually),
called 'daily_maint.sh'

Tries to recycle old archive and tmp files as well
as running disk cleanup.

The log shows several problems:
Moving old tmp files into Recycled/20180907133214
tar: Removing leading `/' from member names
tar: tmp/05F831D4-6E5E-407A-A6CA-16FF47DDD8AA/en-US: Warning: Cannot 
acl_from_text: Invalid argument
tar: tmp/05F831D4-6E5E-407A-A6CA-16FF47DDD8AA: Warning: Cannot 
acl_from_text: Invalid argument
tar: tmp/51DD5395-10EE-4A95-9552-6E319B83C2BF/en-US: Warning: Cannot 
acl_from_text: Invalid argument
tar: tmp/51DD5395-10EE-4A95-9552-6E319B83C2BF: Warning: Cannot 
acl_from_text: Invalid argument

tar: tmp: Warning: Cannot acl_from_text: Invalid argument


In all of these cases it appears that the problem is with directories.

At first thought it was related to presence of 'TRUSTED USER'

But I saw some 'flakeyness' on domain ID's,
where I saw it display the correct text for them,
but scrolling down to look for problems, and back up had the
permissions dialog showing the raw numbers for my domain ID's, but
scrolling again showed them as Domain\ID.

So that's something to consider -- if there is a momentary flake
in the resolution, it might cause a probjust tried those files
again. the "tmp/05" and "tmp/51..."

No errors.

Did something else change besides these probs you looked at?

I have to stress...I've never seen the Cannot_acl_to_text
message before my reporting it a week or so ago

saw instances in use of 'tar' and 'rsync' at this point.

I have seen similar messages out of rsync copying from a windows
dir to a samba dir -- I figured local ID didn't exist on the
remote samba dir.


But have never seen it going between win-directories on the same
machine...that's the new "problem", with current symptoms seeming
to be limited to directories (maybe due to 2 acls)...

Have never had these msgs going from win<->win on same
machine.

Sigh...





--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: gettext - acl tests - cygwin specific code path

[Corinna Vinschen]

On Aug 22 09:49, cyg Simple wrote:
> On 8/22/2018 4:13 AM, Corinna Vinschen wrote:
> > On Aug 21 11:52, cyg Simple wrote:
> >> I've been reviewing the testing of gettext and I have a failure for all
> >> of the acl tests.  I've found that a file without acl will obtain acl if
> >> the mode is changed to 605. STC below.
> >> [...]
> > I just tried this and I can not reproduce the result.  I used your above
> > testcase with fixed chmod invocations.  Eventually:
> > [...]
> C:\opt\cygwin64\tmp\tmpfile0 CYGHOST\cygSimple:(special access:)
> [...]

You deleted the important part of my reply:

Please retry all steps and add the cacls output after each getfacl
output.  Additionally it might be important to see the permissions
of your /tmp dir (ls, getfacl and cacls).  [...]


Corinna

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


signature.asc
Description: PGP signature

Re: gettext - acl tests - cygwin specific code path

[cyg Simple]

On 8/22/2018 4:13 AM, Corinna Vinschen wrote:
> On Aug 21 11:52, cyg Simple wrote:
>> I've been reviewing the testing of gettext and I have a failure for all
>> of the acl tests.  I've found that a file without acl will obtain acl if
>> the mode is changed to 605. STC below.
>>
>> 
>> $ touch /tmp/tmpfile0
>> $ ls -l /tmp/tmpfile0
>> -rw-r--r-- 1 myUser myGroup 0 Aug 21 11:35 /tmp/tmpfile0
>> $ getfacl /tmp/tmpfile0
>> # file: /tmp/tmpfile0
>> # owner: myUser
>> # group: myGroup
>> user::rw-
>> group::r--
>> other:r--
>> $ chmod 600
>> $ ls -l /tmp/tmpfile0
>> -rw--- 1 myUser myGroup 0 Aug 21 11:35 /tmp/tmpfile0
>> $ getfacl /tmp/tmpfile0
>> # file: /tmp/tmpfile0
>> # owner: myUser
>> # group: myGroup
>> user::rw-
>> group::---
>> other:---
>> $ chmod 605
>> $ ls -l /tmp/tmpfile0
>> -rwr-x+ 1 myUser myGroup 0 Aug 21 11:35 /tmp/tmpfile0
>> $ getfacl /tmp/tmpfile0
>> # file: /tmp/tmpfile0
>> # owner: myUser
>> # group: myGroup
>> user::rw-
>> group::---
>> other:r-x
>> user:myUser:---
>> 
> 
> I just tried this and I can not reproduce the result.  I used your above
> testcase with fixed chmod invocations.  Eventually:
> 
>   [...]
>   $ chmod 605 /tmp/tmpfile0
>   $ ls -l /tmp/tmpfile0
>   -rwr-x 1 corinna vinschen 0 Aug 22 09:44 /tmp/tmpfile0
>   $ getfacl /tmp/tmpfile0
>   # file: /tmp/tmpfile0
>   # owner: corinna
>   # group: vinschen
>   user::rw-
>   group::---
>   other::r-x
> 
> Please retry all steps and add the cacls output after each getfacl
> output.  Additionally it might be important to see the permissions
> of your /tmp dir (ls, getfacl and cacls).  Mine has the typical
> 01777 perms.  For testing I also created tmpfile0 in a directory
> with perms 0755, but the outcome was the same, as above.
> 
> Here are my tmpfile0 perms in cacls output, btw., for comparison:
> 
>   $ cacls C:/cygwin64/tmp/tmpfile0
>   C:\cygwin64\tmp\tmpfile0 NULL SID:(DENY)(special access:)
>   READ_CONTROL
> 
>  MYDOMAIN\corinna:(DENY)(special access:)
>   FILE_EXECUTE
> 
>  MYDOMAIN\corinna:(special access:)
>   STANDARD_RIGHTS_ALL
>   DELETE
>   READ_CONTROL
>   WRITE_DAC
>   WRITE_OWNER
>   SYNCHRONIZE
>   STANDARD_RIGHTS_REQUIRED
>   FILE_GENERIC_READ
>   FILE_GENERIC_WRITE
>   FILE_READ_DATA
>   FILE_WRITE_DATA
>   FILE_APPEND_DATA
>   FILE_READ_EA
>   FILE_WRITE_EA
>   FILE_READ_ATTRIBUTES
>   FILE_WRITE_ATTRIBUTES
> 
>  MYDOMAIN\vinschen:(special access:)
>READ_CONTROL
>SYNCHRONIZE
>FILE_READ_ATTRIBUTES
> 
>  MYDOMAIN\vinschen:(DENY)(special access:)
>FILE_READ_DATA
>FILE_READ_EA
>FILE_EXECUTE
> 
>  Everyone:R

C:\opt\cygwin64\tmp\tmpfile0 CYGHOST\cygSimple:(special access:)

STANDARD_RIGHTS_ALL
DELETE
READ_CONTROL
WRITE_DAC
WRITE_OWNER
SYNCHRONIZE
STANDARD_RIGHTS_REQUIRED
FILE_GENERIC_READ
FILE_GENERIC_WRITE
FILE_READ_DATA
FILE_WRITE_DATA
FILE_APPEND

Re: gettext - acl tests - cygwin specific code path

[cyg Simple]

On 8/22/2018 4:15 AM, Corinna Vinschen wrote:
> On Aug 21 19:57, cyg Simple wrote:
>> On 8/21/2018 4:13 PM, Andrey Repin wrote:
>>> Greetings, cyg Simple!
>>>
>>>> During the testing at least one of the tests does `setfacl -m group:0:1
>>>> tmpfile0`.  Obviously this gets a 'permission denied' error as group 0
>>>> doesn't exist.  What do you suggest for reasonable replacement for 0?
>>>
>>> Nothing. Not all systems have a concept of "group 0". Just skip this test.
>>
>> I'm not interested in skipping the test; after all the path for the test
>> is Cygwin specific.  It's just not the correct thing to do for the
>> Cygwin specific path.  I believe 11 to be the correct test and will
>> pursue that upstream.  Marco suggested maybe 544(Administrator) but that
>> doesn't work with a typical user build while doing the same in Linux for
>> root group 0 as a typical user I would need to have elevated privilege
>> in Windows to use 544.
> 
> Exactly as on another system when using group 0.  If these tests are
> really only performed on Cygwin, I don't know what the creator intended.

Cygwin is treated specifically to do this instead of that.  As I review
more cases of the specifically treated Cygwin I think the tests are old
as setfacl options being used don't exist today.

> Otherwise, if you want to reproduce what the testcase did, you should in
> fact use an admin group.

That depends on the purpose of the test and based on the comments the
testing could use any group.  It should also check that the /tmp
filesystem can support ACL as it assumes /tmp to be locally mounted and
skip the testing if not.

-- 
cyg Simple

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: gettext - acl tests - cygwin specific code path

[Andrey Repin]

Greetings, cyg Simple!

> On 8/21/2018 4:13 PM, Andrey Repin wrote:
>> Greetings, cyg Simple!
>> 
>>> During the testing at least one of the tests does `setfacl -m group:0:1
>>> tmpfile0`.  Obviously this gets a 'permission denied' error as group 0
>>> doesn't exist.  What do you suggest for reasonable replacement for 0?
>> 
>> Nothing. Not all systems have a concept of "group 0". Just skip this test.

> I'm not interested in skipping the test; after all the path for the test
> is Cygwin specific.

Then contact the author of these tests and find out what they were thinking
creating them.

> It's just not the correct thing to do for the Cygwin specific path.

That's exactly what I said.
This is just not the right thing to test under Cygwin.

> I believe 11 to be the correct test and will pursue that upstream.

I strongly suggest learning the original intent of the test, before any
"pursuit".

> Marco suggested maybe 544(Administrator) but that doesn't work with a
> typical user build while doing the same in Linux for root group 0 as a
> typical user I would need to have elevated privilege in Windows to use 544.


-- 
With best regards,
Andrey Repin
Wednesday, August 22, 2018 11:59:44

Sorry for my terrible english...


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: gettext - acl tests - cygwin specific code path

[Corinna Vinschen]

On Aug 21 19:57, cyg Simple wrote:
> On 8/21/2018 4:13 PM, Andrey Repin wrote:
> > Greetings, cyg Simple!
> > 
> >> During the testing at least one of the tests does `setfacl -m group:0:1
> >> tmpfile0`.  Obviously this gets a 'permission denied' error as group 0
> >> doesn't exist.  What do you suggest for reasonable replacement for 0?
> > 
> > Nothing. Not all systems have a concept of "group 0". Just skip this test.
> 
> I'm not interested in skipping the test; after all the path for the test
> is Cygwin specific.  It's just not the correct thing to do for the
> Cygwin specific path.  I believe 11 to be the correct test and will
> pursue that upstream.  Marco suggested maybe 544(Administrator) but that
> doesn't work with a typical user build while doing the same in Linux for
> root group 0 as a typical user I would need to have elevated privilege
> in Windows to use 544.

Exactly as on another system when using group 0.  If these tests are
really only performed on Cygwin, I don't know what the creator intended.
Otherwise, if you want to reproduce what the testcase did, you should in
fact use an admin group.


Corinna

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


signature.asc
Description: PGP signature

Re: gettext - acl tests - cygwin specific code path

[Corinna Vinschen]

On Aug 21 11:52, cyg Simple wrote:
> I've been reviewing the testing of gettext and I have a failure for all
> of the acl tests.  I've found that a file without acl will obtain acl if
> the mode is changed to 605. STC below.
> 
> 
> $ touch /tmp/tmpfile0
> $ ls -l /tmp/tmpfile0
> -rw-r--r-- 1 myUser myGroup 0 Aug 21 11:35 /tmp/tmpfile0
> $ getfacl /tmp/tmpfile0
> # file: /tmp/tmpfile0
> # owner: myUser
> # group: myGroup
> user::rw-
> group::r--
> other:r--
> $ chmod 600
> $ ls -l /tmp/tmpfile0
> -rw--- 1 myUser myGroup 0 Aug 21 11:35 /tmp/tmpfile0
> $ getfacl /tmp/tmpfile0
> # file: /tmp/tmpfile0
> # owner: myUser
> # group: myGroup
> user::rw-
> group::---
> other:---
> $ chmod 605
> $ ls -l /tmp/tmpfile0
> -rwr-x+ 1 myUser myGroup 0 Aug 21 11:35 /tmp/tmpfile0
> $ getfacl /tmp/tmpfile0
> # file: /tmp/tmpfile0
> # owner: myUser
> # group: myGroup
> user::rw-
> group::---
> other:r-x
> user:myUser:---
> 

I just tried this and I can not reproduce the result.  I used your above
testcase with fixed chmod invocations.  Eventually:

  [...]
  $ chmod 605 /tmp/tmpfile0
  $ ls -l /tmp/tmpfile0
  -rwr-x 1 corinna vinschen 0 Aug 22 09:44 /tmp/tmpfile0
  $ getfacl /tmp/tmpfile0
  # file: /tmp/tmpfile0
  # owner: corinna
  # group: vinschen
  user::rw-
  group::---
  other::r-x

Please retry all steps and add the cacls output after each getfacl
output.  Additionally it might be important to see the permissions
of your /tmp dir (ls, getfacl and cacls).  Mine has the typical
01777 perms.  For testing I also created tmpfile0 in a directory
with perms 0755, but the outcome was the same, as above.

Here are my tmpfile0 perms in cacls output, btw., for comparison:

  $ cacls C:/cygwin64/tmp/tmpfile0
  C:\cygwin64\tmp\tmpfile0 NULL SID:(DENY)(special access:)
  READ_CONTROL

 MYDOMAIN\corinna:(DENY)(special access:)
  FILE_EXECUTE

 MYDOMAIN\corinna:(special access:)
  STANDARD_RIGHTS_ALL
  DELETE
  READ_CONTROL
  WRITE_DAC
  WRITE_OWNER
  SYNCHRONIZE
  STANDARD_RIGHTS_REQUIRED
  FILE_GENERIC_READ
  FILE_GENERIC_WRITE
  FILE_READ_DATA
  FILE_WRITE_DATA
  FILE_APPEND_DATA
  FILE_READ_EA
  FILE_WRITE_EA
  FILE_READ_ATTRIBUTES
  FILE_WRITE_ATTRIBUTES

 MYDOMAIN\vinschen:(special access:)
   READ_CONTROL
   SYNCHRONIZE
   FILE_READ_ATTRIBUTES

 MYDOMAIN\vinschen:(DENY)(special access:)
   FILE_READ_DATA
   FILE_READ_EA
   FILE_EXECUTE

 Everyone:R



Thanks,
Corinna

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


signature.asc
Description: PGP signature

Re: gettext - acl tests - cygwin specific code path

[cyg Simple]

On 8/21/2018 4:13 PM, Andrey Repin wrote:
> Greetings, cyg Simple!
> 
>> During the testing at least one of the tests does `setfacl -m group:0:1
>> tmpfile0`.  Obviously this gets a 'permission denied' error as group 0
>> doesn't exist.  What do you suggest for reasonable replacement for 0?
> 
> Nothing. Not all systems have a concept of "group 0". Just skip this test.

I'm not interested in skipping the test; after all the path for the test
is Cygwin specific.  It's just not the correct thing to do for the
Cygwin specific path.  I believe 11 to be the correct test and will
pursue that upstream.  Marco suggested maybe 544(Administrator) but that
doesn't work with a typical user build while doing the same in Linux for
root group 0 as a typical user I would need to have elevated privilege
in Windows to use 544.

-- 
cyg Simple

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: gettext - acl tests - cygwin specific code path

[Andrey Repin]

Greetings, cyg Simple!

> During the testing at least one of the tests does `setfacl -m group:0:1
> tmpfile0`.  Obviously this gets a 'permission denied' error as group 0
> doesn't exist.  What do you suggest for reasonable replacement for 0?

Nothing. Not all systems have a concept of "group 0". Just skip this test.


-- 
With best regards,
Andrey Repin
Tuesday, August 21, 2018 23:12:42

Sorry for my terrible english...


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: gettext - acl tests - cygwin specific code path

[Marco Atzeri]

Am 21.08.2018 um 20:58 schrieb cyg Simple:

On 8/21/2018 11:52 AM, cyg Simple wrote:

I've been reviewing the testing of gettext and I have a failure for all
of the acl tests.  I've found that a file without acl will obtain acl if
the mode is changed to 605. STC below.







During the testing at least one of the tests does `setfacl -m group:0:1
tmpfile0`.  Obviously this gets a 'permission denied' error as group 0
doesn't exist.  What do you suggest for reasonable replacement for 0?
I'm thinking 11(Authenticated Users) as the purpose of the test is to
determine if the use of `set_acl (file, -1, mode);` will reset to a file
without acl.



group 0 is likely root.
In theory you can replace with 544 = Administrator
but you need to be an admin.

Otherwise 11 or 545 (Users) should be fine

---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: gettext - acl tests - cygwin specific code path

[cyg Simple]

On 8/21/2018 11:52 AM, cyg Simple wrote:
> I've been reviewing the testing of gettext and I have a failure for all
> of the acl tests.  I've found that a file without acl will obtain acl if
> the mode is changed to 605. STC below.
> 
> 
> $ touch /tmp/tmpfile0
> $ ls -l /tmp/tmpfile0
> -rw-r--r-- 1 myUser myGroup 0 Aug 21 11:35 /tmp/tmpfile0
> $ getfacl /tmp/tmpfile0
> # file: /tmp/tmpfile0
> # owner: myUser
> # group: myGroup
> user::rw-
> group::r--
> other:r--
> $ chmod 600
> $ ls -l /tmp/tmpfile0
> -rw--- 1 myUser myGroup 0 Aug 21 11:35 /tmp/tmpfile0
> $ getfacl /tmp/tmpfile0
> # file: /tmp/tmpfile0
> # owner: myUser
> # group: myGroup
> user::rw-
> group::---
> other:---
> $ chmod 605
> $ ls -l /tmp/tmpfile0
> -rwr-x+ 1 myUser myGroup 0 Aug 21 11:35 /tmp/tmpfile0
> $ getfacl /tmp/tmpfile0
> # file: /tmp/tmpfile0
> # owner: myUser
> # group: myGroup
> user::rw-
> group::---
> other:r-x
> user:myUser:---
> 
> 
> gettext loops through a number of modes and fortunately one of those had
> an owner and other without the group. Anytime the other is set without
> the owner or group having permission we get an ACL for the user which is
> wrong.  A `setfacl -b /tmp/tmpfile0` doesn't correct the information
> from getfacl.
> 

During the testing at least one of the tests does `setfacl -m group:0:1
tmpfile0`.  Obviously this gets a 'permission denied' error as group 0
doesn't exist.  What do you suggest for reasonable replacement for 0?
I'm thinking 11(Authenticated Users) as the purpose of the test is to
determine if the use of `set_acl (file, -1, mode);` will reset to a file
without acl.

-- 
cyg Simple

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

gettext - acl tests - cygwin specific code path

[cyg Simple]

I've been reviewing the testing of gettext and I have a failure for all
of the acl tests.  I've found that a file without acl will obtain acl if
the mode is changed to 605. STC below.


$ touch /tmp/tmpfile0
$ ls -l /tmp/tmpfile0
-rw-r--r-- 1 myUser myGroup 0 Aug 21 11:35 /tmp/tmpfile0
$ getfacl /tmp/tmpfile0
# file: /tmp/tmpfile0
# owner: myUser
# group: myGroup
user::rw-
group::r--
other:r--
$ chmod 600
$ ls -l /tmp/tmpfile0
-rw--- 1 myUser myGroup 0 Aug 21 11:35 /tmp/tmpfile0
$ getfacl /tmp/tmpfile0
# file: /tmp/tmpfile0
# owner: myUser
# group: myGroup
user::rw-
group::---
other:---
$ chmod 605
$ ls -l /tmp/tmpfile0
-rwr-x+ 1 myUser myGroup 0 Aug 21 11:35 /tmp/tmpfile0
$ getfacl /tmp/tmpfile0
# file: /tmp/tmpfile0
# owner: myUser
# group: myGroup
user::rw-
group::---
other:r-x
user:myUser:---


gettext loops through a number of modes and fortunately one of those had
an owner and other without the group. Anytime the other is set without
the owner or group having permission we get an ACL for the user which is
wrong.  A `setfacl -b /tmp/tmpfile0` doesn't correct the information
from getfacl.

-- 
cyg Simple

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin's ACL handling is NOT interoperable with Windows

[Andrey Repin]

Greetings, R0b0t1!

>> Please feel free to provide, using your superior understanding, a detailed 
>> spec
>> for how POSIX ACLs and permissions should be implemented using Windows ACLs
>> while maintaining "canonical" ACL order.

> Or at the very least can another explanation of what is wrong be
> offered? I still don't get it.

As has been said, certain POSIX-specific behavior can't be translated to
canonical ACE order.
Though I'm using noacl mounts, so I yet to face such issue myself.

P.S.
Please tech your mail agent to not quote raw email addresses.
Don't feed spambots.


-- 
With best regards,
Andrey Repin
Tuesday, August 7, 2018 0:08:01

Sorry for my terrible english...


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin's ACL handling is NOT interoperable with Windows

[R0b0t1]

On Mon, Aug 6, 2018 at 10:49 AM, Brian Inglis
 wrote:
>
> Please feel free to provide, using your superior understanding, a detailed 
> spec
> for how POSIX ACLs and permissions should be implemented using Windows ACLs
> while maintaining "canonical" ACL order.

Or at the very least can another explanation of what is wrong be
offered? I still don't get it.

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin's ACL handling is NOT interoperable with Windows

[Brian Inglis]

On 2018-08-05 08:23, Stefan Kanthak wrote:
> Andrey Repin wrote:
>> Greetings, Stefan Kanthak!
>>> PS: <https://cygwin.com/cygwin-ug-net/using.html#pathnames-win32-api>
>>> too states bloody lies:
>>> | The Windows subsystem only supports CWD paths of up to 258 chars.
>> 260 including drive letter.
> WRONG, AGAIN!
> 260 is the value of MAX_PATH, which accounts for the trailing \0, and
> commonly used as
> | char buffer[MAX_PATH];
> I recommend to read
> <https://docs.microsoft.com/en-us/windows/desktop/fileio/naming-a-file>
> VERY careful!
>>> The Win32 API supports pathnames with up to 32767 (Unicode) characters; 
>>> this includes of course the CWD!
>> CWD may be, but command processor does not.
> Neither Cygwin's WRONG documentation nor I referred to the command processor.

Please feel free to provide, using your superior understanding, a detailed spec
for how POSIX ACLs and permissions should be implemented using Windows ACLs
while maintaining "canonical" ACL order.
Windows "canonical" order is preferred because it allows Windows to make short
cut assumptions to meet Windows' security policy objectives.
But MS do not enforce that order in the kernel ACL mechanism because they
recognize that other customers may have different security policy objectives
which may be better achieved using different ACLs and orders.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin's ACL handling is NOT interoperable with Windows

[Michael Wild]

On Sun, Aug 5, 2018 at 5:35 PM Andrey Repin  wrote:

> Greetings, Stefan Kanthak!
>
> > Andrey Repin wrote:
>
> >> Greetings, Stefan Kanthak!
> >>
> >>> PS: <https://cygwin.com/cygwin-ug-net/using.html#pathnames-win32-api>
> >>> too states bloody lies:
> >>
> >>> | The Windows subsystem only supports CWD paths of up to 258 chars.
> >  ~~~
> >>
> >> 260 including drive letter.
>
> > WRONG, AGAIN!
> > 260 is the value of MAX_PATH, which accounts for the trailing \0, and
> > commonly used as
>
> > | char buffer[MAX_PATH];
>
> > I recommend to read
> > <https://docs.microsoft.com/en-us/windows/desktop/fileio/naming-a-file>
> > VERY careful!
>
> >>> The Win32 API supports pathnames with up to 32767 (Unicode)
> characters;
> >>> this includes of course the CWD!
> >>
> >> CWD may be, but command processor does not.
>
> > Neither Cygwin's WRONG documentation nor I referred to the command
> processor.
>
> I think, this is an appropriate response to the underlying issue:
> https://xkcd.com/386


+1 from me.

I propose to ignore Stefan until he learns his manners, is less
cantankerous and maybe even volunteers to submit a patch if indeed there is
a problem with the ACL handling (although, to be honest, I can hardly
imagine it, Corinna being involved...).

Michael

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin's ACL handling is NOT interoperable with Windows

[Andrey Repin]

Greetings, Stefan Kanthak!

> Andrey Repin wrote:

>> Greetings, Stefan Kanthak!
>> 
>>> PS: 
>>> too states bloody lies:
>> 
>>> | The Windows subsystem only supports CWD paths of up to 258 chars.
>  ~~~
>> 
>> 260 including drive letter.

> WRONG, AGAIN!
> 260 is the value of MAX_PATH, which accounts for the trailing \0, and
> commonly used as

> | char buffer[MAX_PATH];

> I recommend to read
> 
> VERY careful!

>>> The Win32 API supports pathnames with up to 32767 (Unicode) characters;
>>> this includes of course the CWD!
>> 
>> CWD may be, but command processor does not.

> Neither Cygwin's WRONG documentation nor I referred to the command processor.

I think, this is an appropriate response to the underlying issue:
https://xkcd.com/386/


-- 
With best regards,
Andrey Repin
Sunday, August 5, 2018 18:21:42

Sorry for my terrible english...


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin's ACL handling is NOT interoperable with Windows

[Stefan Kanthak]

Andrey Repin wrote:

> Greetings, Stefan Kanthak!
> 
>> PS: 
>> too states bloody lies:
> 
>> | The Windows subsystem only supports CWD paths of up to 258 chars.
 ~~~
> 
> 260 including drive letter.

WRONG, AGAIN!
260 is the value of MAX_PATH, which accounts for the trailing \0, and
commonly used as

| char buffer[MAX_PATH];

I recommend to read

VERY careful!

>> The Win32 API supports pathnames with up to 32767 (Unicode) characters;
>> this includes of course the CWD!
> 
> CWD may be, but command processor does not.

Neither Cygwin's WRONG documentation nor I referred to the command processor.

regards
Stefan

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin's ACL handling is NOT interoperable with Windows

[Andrey Repin]

Greetings, Stefan Kanthak!

> PS: 
> too states bloody lies:

> | The Windows subsystem only supports CWD paths of up to 258 chars.

260 including drive letter.

> The Win32 API supports pathnames with up to 32767 (Unicode) characters;
> this includes of course the CWD!

CWD may be, but command processor does not.
I had a wonderful sex just a few hours ago trying to handle *.eml in a
directory and missing on 3 files over and over again, until I've listed
them with dir and see them cut in the middle.


-- 
With best regards,
Andrey Repin
Sunday, August 5, 2018 17:02:07

Sorry for my terrible english...


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin's ACL handling is NOT interoperable with Windows

[Michael Wild]

Hi Stefan

On Sat, 4 Aug 2018, 19:12 Stefan Kanthak,  wrote:

> [...]
> As Cygwin is a guest in the house of Windows, it should respect its hosts
> house rules; instead it but violates them, and blames the host for its
> faults!

 [...]
>
> Fix Cygwin's BUGGY ACL creation!
>
> [...]
>
> PS: <https://cygwin.com/cygwin-ug-net/using.html#pathnames-win32-api>
> too states bloody lies:


Wow, man, you really know how to make people *not* want to help you. Cygwin
is a volunteer effort. Nobody ows you the tiniest bit. You paid for
nothing, you got something for free and now you curse about it?! Show some
humility and respect, tone it down a bit. Works wonders.

Michael

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin's ACL handling is NOT interoperable with Windows

[Marco Atzeri]

Am 04.08.2018 um 19:11 schrieb Stefan Kanthak:

Hi,


Hi Stefan,



<https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-files> states:

| There's just one problem when trying to map the POSIX permission model
| onto the Windows permission model.
...
| Canonical ACLs are unable to reflect each possible combination of POSIX
| permissions.
...
| Again: This works on all supported versions of Windows. Only the GUIs
| aren't able (or willing) to deal with that order.

These last two statements are wrong:

* the first statement holds ONLY because of the LIMITATION of the POSIX
   permissions; it is WRONG for the general case, which ALL Windows
   interfaces/components need to consider and handle, EVERYWHERE!


Cygwin aims to POSIX compliance, using the tool given by Windows.
Have you tested all the possible POSIX permissions and verified that
it is possible to replicate with windows ACL ?
Please note that ACL were not created by Microsoft.


* the second statement is a blatant lie: to guarantee CORRECT
   interpretation of arbitrary ACLs, ALL Windows interfaces/components,
   not just the "GUIs", MUST create CANONICAL ACLs only.


That is your opinion.
About the "lie", may I suggest you an old Italian classic

"Galateo of Manners & Behaviours by Giovanni Della Casa"
http://www.gutenberg.org/ebooks/47993



   This especially means that not just Windows Explorer, but also the
   command processor with its builtin COPY command as well as the
   CopyFile() <https://msdn.microsoft.com/en-us/library/aa220078.aspx>
   API (just to pick 3 examples) bring INHERITED ACEs into their PROPER
   canonical order.

As Cygwin is a guest in the house of Windows, it should respect its hosts
house rules; instead it but violates them, and blames the host for its
faults!


What is your problem ?

If you don't like how cygwin is behaving, you can:

- stop to use it
- propose a change (with a patch of course)
- learn to use it without venting


Fix Cygwin's BUGGY ACL creation!


Cool down. You paid nothing, we own you nothing.

No one here is paid to solve your "theorical" problem;
if you know a better way to handle the POSIX permissions
show us the code and we can discuss.


regards
Stefan Kanthak


Best Regards
Marco

---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Cygwin's ACL handling is NOT interoperable with Windows

[Stefan Kanthak]

Hi,

<https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-files> states:

| There's just one problem when trying to map the POSIX permission model
| onto the Windows permission model.
...
| Canonical ACLs are unable to reflect each possible combination of POSIX
| permissions.
...
| Again: This works on all supported versions of Windows. Only the GUIs
| aren't able (or willing) to deal with that order.

These last two statements are wrong:

* the first statement holds ONLY because of the LIMITATION of the POSIX
  permissions; it is WRONG for the general case, which ALL Windows
  interfaces/components need to consider and handle, EVERYWHERE!

* the second statement is a blatant lie: to guarantee CORRECT
  interpretation of arbitrary ACLs, ALL Windows interfaces/components,
  not just the "GUIs", MUST create CANONICAL ACLs only.

  This especially means that not just Windows Explorer, but also the
  command processor with its builtin COPY command as well as the
  CopyFile() <https://msdn.microsoft.com/en-us/library/aa220078.aspx>
  API (just to pick 3 examples) bring INHERITED ACEs into their PROPER
  canonical order.

As Cygwin is a guest in the house of Windows, it should respect its hosts
house rules; instead it but violates them, and blames the host for its
faults!

| But don't even think of pressing OK...

Fortunately nobody need to press OK here, but everybody can demonstrate
Cygwin's defects as follows:

* Use Windows Explorer, the command processor or CopyFile() to copy an
  arbitrary file into a directory created by Cygwin, then inspect its
  ACL!

* Use Windows' Explorer, the command processor or CopyFile() to copy an
  arbitrary file created by Cygwin into an arbitrary directory created
  by Cygwin, then inspect its ACL.

* Use Windows Explorer or the command processor to create a subdirectory
  in a directory created by Cygwin, then inspects its ACL!

Do these ACLs reflect the intended or expected POSIX permissions?
OUCH³!


Win32 functions like CreateFile() and CreateDirectory()
(see <https://msdn.microsoft.com/en-us/library/aa363858.aspx>
and <https://msdn.microsoft.com/en-us/library/aa363855.aspx>)
allow to write NON-canonical ACLs via direct specification of a
"security descriptor"; if NULL is specified (which is the typical
case), they create canonical ACLs, reordering inherited ACEs!

Unfortunately their documentation misses remarks on the proper
canonical order of ACLs, and how inherited but UNORDERED ACLs are
handled.

The documentation of other Win32 functions, for example
AddAccessAllowedAce() and AddAccessDeniedAce()
(see <https://msdn.microsoft.com/en-us/library/aa374947.aspx>
and <https://msdn.microsoft.com/de-de/library/aa374962.aspx>)
but EXPLICITLY states:

| These functions do not automatically place the new ACE in the
| proper canonical order. It is the caller's responsibility to
| ensure that the ACL is in canonical order by adding ACEs in the
| proper sequence.

<https://msdn.microsoft.com/en-us/library/aa374951.aspx> and
<https://msdn.microsoft.com/en-us/library/aa374964.aspx> go further:

| The caller must ensure that ACEs are added to the DACL in the
| correct order. For more information, see Order of ACEs in a DACL.

<https://msdn.microsoft.com/en-us/library/aa379298.aspx>
<https://msdn.microsoft.com/en-us/library/aa446683.aspx>
<https://technet.microsoft.com/en-us/library/cc781716.aspx>

| The canonical order ensures that an explicit access-denied ACE is
| enforced regardless of any explicit access-allowed ACE.

JFTR: for the algorithm used in Windows and why the proper order of
  ACLs is crucial see
  <https://blogs.msdn.microsoft.com/oldnewthing/20070608-00/?p=26503>

  Also see <http://www.ntfs.com/ntfs-permissions-acl-use.htm>

Fix Cygwin's BUGGY ACL creation!

regards
Stefan Kanthak

PS: <https://cygwin.com/cygwin-ug-net/using.html#pathnames-win32-api>
too states bloody lies:

| The Windows subsystem only supports CWD paths of up to 258 chars.

The Win32 API supports pathnames with up to 32767 (Unicode) characters;
this includes of course the CWD!


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: GNU Tar v1.29 ACL File/Folder Permissions Question/Problem

[Brian Inglis]

On 2017-07-22 10:16, Ken Brown wrote:
> On 7/21/2017 4:59 PM, Timothy Beryl Grahek wrote:
>> Whenever I have ACL enabled in /etc/fstab, I run into file access
>> problems with GNU Tar. To be clear, a simple scenario is to tar a few
>> folders, then extract them. In numerous cases, I am unable to enter
>> the folders I have extracted without entering a "chmod 744" as an
>> administrator.
>> I have consequently disabled ACL in /etc/fstab, which has fixed this problem.
>> Anybody have any ideas as to why this happens and how to avoid it
>> without disabling ACL?
> 
> Could the problem be caused by the default ACL on the directory you're
> extracting into?  If so, the -b or -k option to 'setfacl' might help.  See
> 
>   https://cygwin.com/cygwin-ug-net/setfacl.html

Could be lack of any DACL?
Don't ever use setfacl -k to remove DACLs from any directory where you may ever
use Windows programs to create, move, or drop a file, as it may end up with deny
all permissions, and you have to go elevated/admin to restore access.
BTDT ;^>
I use native Windows, not X, programs when I want to use GUIs, and that
occasionally causes problems like this.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: GNU Tar v1.29 ACL File/Folder Permissions Question/Problem

[Ken Brown]

On 7/21/2017 4:59 PM, Timothy Beryl Grahek wrote:

Hi all,

Whenever I have ACL enabled in /etc/fstab, I run into file access
problems with GNU Tar. To be clear, a simple scenario is to tar a few
folders, then extract them. In numerous cases, I am unable to enter
the folders I have extracted without entering a "chmod 744" as an
administrator.

I have consequently disabled ACL in /etc/fstab, which has fixed this problem.

Anybody have any ideas as to why this happens and how to avoid it
without disabling ACL?


Could the problem be caused by the default ACL on the directory you're 
extracting into?  If so, the -b or -k option to 'setfacl' might help.  See


  https://cygwin.com/cygwin-ug-net/setfacl.html

Ken


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Issues with ACL settings after updating to the latest cygwin.dll - correction

[Corinna Vinschen]

On May 30 16:50, Erik Soderquist wrote:
> On Mon, May 30, 2016 at 6:35 AM, Corinna Vinschen wrote:
> >
> > Can you, by any chance, also send the output of `cd /tmp; icacls .'?
> >
> 
> Unfortunately no, corporate machine, and was replaced less than a week
> ago.  The new machine does not have the same issue, though I have not
> tested (and probably won't be able to test) the upgrade scenarios that
> seem to be associated with this issue unless I stumble upon it on a
> different machine.

Too bad, but that's life.


Corinna

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


signature.asc
Description: PGP signature

Re: Issues with ACL settings after updating to the latest cygwin.dll - correction

[Erik Soderquist]

On Mon, May 30, 2016 at 6:35 AM, Corinna Vinschen wrote:
>
> Can you, by any chance, also send the output of `cd /tmp; icacls .'?
>

Unfortunately no, corporate machine, and was replaced less than a week
ago.  The new machine does not have the same issue, though I have not
tested (and probably won't be able to test) the upgrade scenarios that
seem to be associated with this issue unless I stumble upon it on a
different machine.

-- Erik

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Issues with ACL settings after updating to the latest cygwin.dll - correction

[Corinna Vinschen]

On Apr 29 12:03, Erik Soderquist wrote:
> I'm having a similar issue with strange acl results... I wish I knew
> which update triggered this, but I'd ignored and/or worked around
> it...
> 
> I can reproduce it with the following:
> 
> user@localhost ~
> $ touch /tmp/foo
> 
> user@localhost ~
> $ chmod 700 /tmp/foo
> 
> user@localhost ~
> $ echo foo>/tmp/foo
> -bash: /tmp/foo: Permission denied
> 
> user@localhost ~
> $ ls -la /tmp
> total 20
> drwxrwxrwx+ 1 user Administrators 0 Apr 29 11:42 .
> dr-xrwxr-x+ 1 Administrators  Administrators 0 Mar  9 17:00 ..
> -rwx--+ 1 user Domain Users   0 Apr 29 11:42 foo
> 
> 
> result of the acl commands, as I've seen them requested are:
> 
> user@localhost /tmp
> $ cacls foo
> [...]
> user@localhost /tmp
> $ icacls foo
> foo NewDomain\user:(DENY)(W,RD,REA,DC)
> NewDomain\user:(F)
> NewDomain\user:(R,W)
> NewDomain\Domain Users:(DENY)(W,RD,REA,DC)
> OldDomain\Domain Users:(DENY)(W,RD,REA,DC)
> NewDomain\Domain Users:(R,W)
> BUILTIN\Administrators:(R,W)
> OldDomain\Domain Users:(R,W)
> Everyone:(Rc,S,RA)

Can you, by any chance, also send the output of `cd /tmp; icacls .'?


Thanks,
Corinna

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


signature.asc
Description: PGP signature

Re: Issues with ACL settings after updating to the latest cygwin.dll - correction

[Erik Soderquist]

I'm having a similar issue with strange acl results... I wish I knew
which update triggered this, but I'd ignored and/or worked around
it...

I can reproduce it with the following:

user@localhost ~
$ touch /tmp/foo

user@localhost ~
$ chmod 700 /tmp/foo

user@localhost ~
$ echo foo>/tmp/foo
-bash: /tmp/foo: Permission denied

user@localhost ~
$ ls -la /tmp
total 20
drwxrwxrwx+ 1 user Administrators 0 Apr 29 11:42 .
dr-xrwxr-x+ 1 Administrators  Administrators 0 Mar  9 17:00 ..
-rwx--+ 1 user Domain Users   0 Apr 29 11:42 foo


result of the acl commands, as I've seen them requested are:

user@localhost /tmp
$ cacls foo
C:\cygwin64\tmp\foo NewDomain\user:(DENY)(special access:)
  FILE_READ_DATA
  FILE_WRITE_DATA
  FILE_APPEND_DATA
  FILE_READ_EA
  FILE_WRITE_EA
  FILE_DELETE_CHILD
  FILE_WRITE_ATTRIBUTES

NewDomain\user:F
NewDomain\user:(special access:)
  READ_CONTROL
  SYNCHRONIZE
  FILE_GENERIC_READ
  FILE_GENERIC_WRITE
  FILE_READ_DATA
  FILE_WRITE_DATA
  FILE_APPEND_DATA
  FILE_READ_EA
  FILE_WRITE_EA
  FILE_READ_ATTRIBUTES
  FILE_WRITE_ATTRIBUTES

NewDomain\Domain Users:(DENY)(special access:)
   FILE_READ_DATA
   FILE_WRITE_DATA
   FILE_APPEND_DATA
   FILE_READ_EA
   FILE_WRITE_EA
   FILE_DELETE_CHILD
   FILE_WRITE_ATTRIBUTES

OldDomain\Domain Users:(DENY)(special access:)
  FILE_READ_DATA
  FILE_WRITE_DATA
  FILE_APPEND_DATA
  FILE_READ_EA
  FILE_WRITE_EA
  FILE_DELETE_CHILD
  FILE_WRITE_ATTRIBUTES

NewDomain\Domain Users:(special access:)
   READ_CONTROL
   SYNCHRONIZE
   FILE_GENERIC_READ
   FILE_GENERIC_WRITE
   FILE_READ_DATA
   FILE_WRITE_DATA
   FILE_APPEND_DATA
   FILE_READ_EA
   FILE_WRITE_EA
   FILE_READ_ATTRIBUTES
   FILE_WRITE_ATTRIBUTES

BUILTIN\Administrators:(special access:)
   READ_CONTROL
   SYNCHRONIZE
   FILE_GENERIC_READ
   FILE_GENERIC_WRITE
   FILE_READ_DATA
   FILE_WRITE_DATA
   FILE_APPEND_DATA
   FILE_READ_EA
   FILE_WRITE_EA
   FILE_READ_ATTRIBUTES
   FILE_WRITE_ATTRIBUTES

OldDomain\Domain Users:(special access:)
  READ_CONTROL
  SYNCHRONIZE
  FILE_GENERIC_READ
  FILE_GENERIC_WRITE
  FILE_READ_DATA
  FILE_WRITE_DATA
  FILE_APPEND_DATA
  FILE_READ_EA
  FILE_WRITE_EA
  FILE_READ_ATTRIBUTES
  FILE_WRITE_ATTRIBUTES

Everyo

Re: Issues with ACL settings after updating to the latest cygwin.dll - correction

[Corinna Vinschen]

On Mar  7 20:12, aki...@free.fr wrote:
> Hi, Corinna
> 
> Here an example of one problematic ACL
> Here on /etc directory (here on remote system)
> [...]
> # file: .
> # owner: Unknown+User
> # group: Unknown+Group
> user::rwx
> group::r-x
> other:r-x
> default:user::rwx
> default:group::r-x
> default:other:r-x
> 
> $ icacls .
> . NULL SID:(DENY)(Rc,S)
>   S-1-5-21-1315901005-2739448750-426064240-1000:(F)
>   S-1-5-21-1315901005-2739448750-426064240-513:(RX)
>   Tout le monde:(RX)
>   NULL SID:(OI)(CI)(IO)(DENY)(Rc,S)
>   CREATEUR PROPRIETAIRE:(OI)(CI)(IO)(F)
>   GROUPE CREATEUR:(OI)(CI)(IO)(RX)
>   Tout le monde:(OI)(CI)(IO)(RX)

I assume your machines are not in a domain?  The SIDs of that user on
the remote machine are unknown to Cygwin.  For the time being, Cygwin
can't automatically fetch SIDs on remote shares unless you're using
Active Directory.

To fix that locally you have to create /etc/passwd and /etc/group
entries for the remote accounts using `mkpasswd -l '
and `mkgroup -l '.  Other than that, the above
SID and it's evaluation via getfacl are perfectly valid.

> When I get Security Tab for this directory,
> Windows returns a popup message "Authorizations on etc unordered, some 
> entries may be skipped"
> After answering OK, a new panel is shown and as I click on Advanced 
> Autorisations
> Windows returns a message proposing to order the ACLs.
> After ordering, I get :

Again, don't do that.  What do you want to do *exactly*?  Do you want to
change the owner and group of the file?  If so, use Cygwin's chown,
please.  Never rearrange Cygwin ACLs using non-Cygwin tools if you want
them to stay functional for the reasons outlined in my previous replies.


Corinna

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


signature.asc
Description: PGP signature

Re: Issues with ACL settings after updating to the latest cygwin.dll - correction

[akikij]

Hi, Corinna

Here an example of one problematic ACL
Here on /etc directory (here on remote system)

$ cacls .
...\ws\njcyg\etc NULL SID:(DENY)(accès spécial :)
READ_CONTROL

   F
   R
   Tout le monde:R
   NULL SID:(OI)(CI)(IO)(DENY)(accès spécial :)
READ_CONTROL

   CREATEUR PROPRIETAIRE:(OI)(CI)(IO)F
   GROUPE CREATEUR:(OI)(CI)(IO)R
   Tout le monde:(OI)(CI)(IO)R

$ getfacl .
# file: .
# owner: Unknown+User
# group: Unknown+Group
user::rwx
group::r-x
other:r-x
default:user::rwx
default:group::r-x
default:other:r-x

$ icacls .
. NULL SID:(DENY)(Rc,S)
  S-1-5-21-1315901005-2739448750-426064240-1000:(F)
  S-1-5-21-1315901005-2739448750-426064240-513:(RX)
  Tout le monde:(RX)
  NULL SID:(OI)(CI)(IO)(DENY)(Rc,S)
  CREATEUR PROPRIETAIRE:(OI)(CI)(IO)(F)
  GROUPE CREATEUR:(OI)(CI)(IO)(RX)
  Tout le monde:(OI)(CI)(IO)(RX)

When I get Security Tab for this directory,
Windows returns a popup message "Authorizations on etc unordered, some entries 
may be skipped"
After answering OK, a new panel is shown and as I click on Advanced 
Autorisations
Windows returns a message proposing to order the ACLs.
After ordering, I get :
$ icacls .
. NULL SID:(OI)(CI)(DENY)(Rc,S)
  CREATEUR PROPRIETAIRE:(OI)(CI)(IO)(F)
  GROUPE CREATEUR:(OI)(CI)(IO)(RX)
  S-1-5-21-1315901005-2739448750-426064240-1000:(F)
  S-1-5-21-1315901005-2739448750-426064240-513:(RX)
  Tout le monde:(OI)(CI)(RX)

getfacl . is unchanged
I don't know which ACLs are or not skipped.
But at a moment of my application, I get a permission denied not for /etc (here 
an example),
but for another object with analog properties.
Today, I am obliged to return to 2.3 version to keep my application operational.

Regards


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Issues with ACL settings after updating to the latest cygwin.dll - correction

[Corinna Vinschen]

On Mar  5 18:49, aki...@free.fr wrote:
> Hi, Corinna
> 
> To be clear about my problems about ACL.
> A very simple example to observe.
> 
> I go to the root disk (C:\ or /cygdrive/c upon the system)
> I can't create a file here (normally protected).
> So I use administrator rights to do that with cmd and bash.
> 
> In cmd :
> C:\>echo > xx
> C:\>cacls xx
> C:\xx BUILTIN\Administrateurs:(ID)F
>   AUTORITE NT\Système:(ID)F
>   BUILTIN\Utilisateurs:(ID)R
>   AUTORITE NT\Utilisateurs authentifiés:(ID)C
> 
> Sorry I am french, but I say Ok why not.

No worries, my french isn't very good, but the group names are
easily understood.

> 
> In bash :
> user@HOST /cygdrive/c -- my prompt bash not repeated after
> $ echo > x
> $ cacls x

Pleae don't use cacls.  Use icacls instead.  Cacls output is much less
readable and, above all, missing important details.  Yeah, icacls is
buggy, but I know what to ignore there ;)

> [...]
> Sorry, it's a very long data and I can't really say if it's ok or not.

It is correct.  Icacls output would have been shorter.

> Why such as complexity ?

It's not overly complex, but admittedly, it's not yet really documented.
Quoting the source code comment:

============
/* How does a correctly constructed new-style Windows ACL claiming to be a
   POSIX ACL look like?

   - NULL deny ACE (special bits, CLASS_OBJ).

   - USER_OBJ deny.  If the user has less permissions than the sum of CLASS_OBJ
 (or GROUP_OBJ if CLASS_OBJ doesn't exist) and OTHER_OBJ, deny the excess
 permissions so that group and other perms don't spill into the owner perms.

   USER_OBJ deny ACE   == ~USER_OBJ & (CLASS_OBJ | OTHER_OBJ)
 or
   USER_OBJ deny ACE   == ~USER_OBJ & (GROUP_OBJ | OTHER_OBJ)

   - USER deny.  If a user has more permissions than CLASS_OBJ, or if the
 user has less permissions than OTHER_OBJ, deny the excess permissions.

   USER deny ACE   == (USER & ~CLASS_OBJ) | (~USER & OTHER_OBJ)

   - USER_OBJ  allow ACE
   - USER  allow ACEs

   The POSIX permissions returned for a USER entry are the allow bits alone!

   - GROUP{_OBJ} deny.  If a group has more permissions than CLASS_OBJ,
 or less permissions than OTHER_OBJ, deny the excess permissions.

   GROUP{_OBJ} deny ACEs  == (GROUP & ~CLASS_OBJ)

   - GROUP_OBJ  allow ACE
   - GROUP  allow ACEs

   The POSIX permissions returned for a GROUP entry are the allow bits alone!

   - 2. GROUP{_OBJ} deny.  If a group has less permissions than OTHER_OBJ,
 deny the excess permissions.

   2. GROUP{_OBJ} deny ACEs  == (~GROUP & OTHER_OBJ)

   - OTHER_OBJ  allow ACE

   Rinse and repeat for default ACEs with INHERIT flags set.

   - Default NULL deny ACE (S_ISGID, CLASS_OBJ). */
====

The comment still uses the old Solaris macro names, sorry.  Basically
the NULL deny ACE serves two purposes:

- An ACL starting with a NULL deny SID is immediately recognized as
  a Cygwin POSIX ACL.  That leads to speed advantages because in
  contrast to a non-Cygwin ACL the effective permissiosns don't have
  to be computed the hard way.  A POSIX ACL always transports the full
  permission set including effective perms.

- The NULL deny SID also transports information.  It contains the
  special POSIX permission bits (S_ISVTX, S_ISGID, S_ISUID) as well
  as the POSIX ACL MASK value (CLASS_OBJ == Solaris name for MASK).

So the MASK value is in the NULL deny ACE.  And here's where the other
DENY ACEs come into the picture:  In a Cygwin ACL, the allow ACE for a
trustee contains the *real* perms, otherwise we had no way to reflect
the POSIX ACL correctly.  So the *deny* ACE for a trustee allows to
create the effective perms.  Example:

real group perms:  r-x
mask:  rw-
--> effective perms:   r--

Given that the ACE for the group reflects the real perms (r-x)
a deny ACE has to be added to disallow the execute perms.

Make sense?

> All that to say, ACLs affected to file are may be surprising but work A 
> LITTLE BIT, yes more ...
> But in some cases NOT.

This is what I need to know.  What *exactly* doesn't work?

> In my cygwin application, sometimes I fall in a situation where I am
> obliged to reorder the ACEs to continue correctly. I say obliged and
> it's the first problem. Who create this situation ?  Always I have
> seen a NULL SID ACE in such a case. That's the reason I don't like it.

The NULL ACE is very likely not the problem.  I must know what you
try and what you expect, and how Cygwin fails in this scenario.
Please don't touch the ACL using WIndows tools.  And for this
report, please don't touch the ACL at all

Re: Issues with ACL settings after updating to the latest cygwin.dll - correction

[akikij]

Hi, Corinna

To be clear about my problems about ACL.
A very simple example to observe.

I go to the root disk (C:\ or /cygdrive/c upon the system)
I can't create a file here (normally protected).
So I use administrator rights to do that with cmd and bash.

In cmd :
C:\>echo > xx
C:\>cacls xx
C:\xx BUILTIN\Administrateurs:(ID)F
  AUTORITE NT\Système:(ID)F
  BUILTIN\Utilisateurs:(ID)R
  AUTORITE NT\Utilisateurs authentifiés:(ID)C

Sorry I am french, but I say Ok why not.

In bash :
user@HOST /cygdrive/c -- my prompt bash not repeated after
$ echo > x
$ cacls x
C:\x NULL SID:(DENY)(accès spécial :)
  READ_CONTROL
  FILE_WRITE_EA
  FILE_EXECUTE
  FILE_DELETE_CHILD

 ASUS38\andre:(accès spécial :)
  STANDARD_RIGHTS_ALL
  DELETE
  READ_CONTROL
  WRITE_DAC
  WRITE_OWNER
  SYNCHRONIZE
  STANDARD_RIGHTS_REQUIRED
  FILE_GENERIC_READ
  FILE_GENERIC_WRITE
  FILE_READ_DATA
  FILE_WRITE_DATA
  FILE_APPEND_DATA
  FILE_READ_EA
  FILE_WRITE_EA
  FILE_READ_ATTRIBUTES
  FILE_WRITE_ATTRIBUTES

 BUILTIN\Administrateurs:(DENY)(accès spécial :)
 FILE_EXECUTE

 AUTORITE NT\Utilisateurs authentifiés:(DENY)(accès spécial 
   FILE_EXECUTE

 AUTORITE NT\Système:(DENY)(accès spécial :)
 FILE_EXECUTE

 BUILTIN\Utilisateurs:(DENY)(accès spécial :)
  FILE_EXECUTE

 ASUS38\Aucun:(accès spécial :)
  READ_CONTROL
  SYNCHRONIZE
  FILE_GENERIC_READ
  FILE_READ_DATA
  FILE_READ_EA
  FILE_READ_ATTRIBUTES

 BUILTIN\Administrateurs:(accès spécial :)
 READ_CONTROL
 SYNCHRONIZE
 FILE_GENERIC_READ
 FILE_GENERIC_WRITE
 FILE_GENERIC_EXECUTE
 FILE_READ_DATA
 FILE_WRITE_DATA
 FILE_APPEND_DATA
 FILE_READ_EA
 FILE_WRITE_EA
 FILE_EXECUTE
 FILE_READ_ATTRIBUTES
 FILE_WRITE_ATTRIBUTES

 AUTORITE NT\Utilisateurs authentifiés:(accès spécial :)
   READ_CONTROL
   SYNCHRONIZE
   FILE_GENERIC_READ
   FILE_GENERIC_WRITE
   FILE_GENERIC_EXECUTE
   FILE_READ_DATA
   FILE_WRITE_DATA
   FILE_APPEND_DATA
   FILE_READ_EA
   FILE_WRITE_EA
   FILE_EXECUTE
   FILE_READ_ATTRIBUTES
   FILE_WRITE_ATTRIBUTES

 AUTORITE NT\Système:(accès spécial :)
 READ_CONTROL
 SYNCHRONIZE
 FILE_GENERIC_READ
 FILE_GENERIC_WRITE
 FILE_GENERIC_EXECUTE
 FILE_READ_DATA
 FILE_WRITE_DATA
 FILE_APPEND_DATA
 FILE_READ_EA
 FILE_WRITE_EA
 FILE_EXECUTE
 FILE_READ_ATTRIBUTES
 FILE_WRITE_ATTRIBUTES

 BUILTIN\Utilisateurs:R
 Tout le monde:(accès spécial :)
   READ_CONTROL
   SYNCHRONIZE
   FILE_GENERIC_READ
   FILE_READ_DATA
   FILE_READ_EA
   FILE_READ_ATTRIBUTES
-
Sorry, it's a very long data and I can't really say if it's ok or not.
Why such as complexity ?
I understand the DENY FILE_EXECUTE (It's the unix philosophy for file creation)
I don't understand NULL SID DENY - and how it's translated in getfacl.
Now if I compare cacls xx created by cmd they are same in bash and cmd.
Now if I compare getfacl (more readable) for x and of xx, I have :
$ getfacl.exe x
# file: x
# owner: user
# group: Aucun
user::rw-
group::r--
group:root:rwx  #effective:rw-
group:Utilisateurs authentifiés:rwx #effective:rw-
group:Système:rwx  #effective:rw-
group:Utilisateurs:r-x  

Re: Issues with ACL settings after updating to the latest cygwin.dll - correction

[Corinna Vinschen]

Hi Akiki(?),

On Mar  4 16:43, aki...@free.fr wrote:
> Hi,
> I have the different problems you have about this new security right NULL SID 
> DENY added to some files.

I still doubt the NULL ACE is the actual culprit of whatever you
observe.  A NULL ACE doesn't affect your permissions, unless you have a
NULL SID in your user token, which is extremly unlikely.

> Sometimes also Windows can't access files concerned.
> He considered security rigths unordered and I have to class them before 
> continue.
> It's too difficult for me to help you to correct the problem.

No, I don't think so.

First of all, the order in the ACL is deliberate to provide an emulation
of POSIX permissions.  Don't reorder the ACL using Windows means, this
*will* break the ACL evaluation.

Please also note that the Windows OS does *not* fail to evaluate an
ACL just because it's not in the so-called "canonical order".  The
OS strictly evaluates the ACL top-down, from the first to the last ACE,
without worrying about the order.  Only the GUI and certain Windows
tools written to manipulate an ACL (e.g. icacls) will choke on such ACLs.
Don't use such tools on Cygwin-created ACLs.  Use Cygwin's chmod, chown,
and setfacl for this.

My problem is this: You're the third person on this list reporting a
problem along the lines of "ACL doesn't work with Windows", without
giving me a clear reproducer.

What I need is a clear description what *exactly* you do and what
*exactly* fails.  I assume you created a file using some Cygwin tool
and then try to access it from non-Cygwin tools.  Are you unable to
read or write the file using that Windows tool?  Are you expecting
to double click on the file to execute something?  I really need a 
simple description which is easily reproduced using Windows system
tools.

What I then also need is that you do *NOT* try to *fix* the ACL, but
rather send me

- icacls output of the file and its parent dir
- getfacl output of the file and its parent dir

*If* there's a real problem, I need to be able to reproduce it,
otherwise I won't be able to fix it in Cygwin.


Thanks,
Corinna

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


signature.asc
Description: PGP signature

Issues with ACL settings after updating to the latest cygwin.dll - correction

[akikij]

Hi,
I have the different problems you have about this new security right NULL SID 
DENY added to some files.
Sometimes also Windows can't access files concerned.
He considered security rigths unordered and I have to class them before 
continue.
It's too difficult for me to help you to correct the problem.
I give only tracks to correct the effects to return to a clean situation.

I have a solution to list all files concerned in a directory tree:
#!/bin/bash
#   List on stdout objects with DENY
if [ $# -eq 0 ] ; then echo "Usage $0 path" ; exit 1 ; fi
cd "$1" || { echo "Bad path" ; exit 1; }
find . |grep -v -E '^\.$|RECYCLE.BIN|RECYCLER|System Volume Information'|while 
read i 
do  #echo "$i"
1>&2 echo -en "$i\\r" #to see progression
j=$(cygpath "$i")
c=$(2>/dev/null cacls "$j" /L)
if [ $? -ne 0 ] ; then
s=$(file "$i"|grep 'symbolic link to')
if [ -z "$s" ] ; then echo "not found $j" ; fi
continue
fi
s=$(echo "$c"|grep -i 'NULL SID:(DENY)')
if [ ! -z "$s" ] ; then
echo "$c" 
fi 
done |tee /tmp/1

I use here /tmp/1 as buffer. I can edit it before to submit to the next 
solution.
It's more safe for the moment.

I have another solution to patch security items contained in this buffer (here 
/tmp/1)
#!/bin/bash
#   Patch objects recognized having NULL SID right
#   one to one - with icacls - exit at the 1st error
ws=/tmp/NULSID  #root name for 2 temporary files, .org .new as suffixe
cat /tmp/1|grep '^.:'|while read -r i ; do
j=$(echo "$i"|sed 's/ NULL SID.*//')
echo "  chg $j"
corg="$ws.org"
cnew="$ws.new"
icacls "$j" /save $(cygpath -w "$corg") || exit 1
#edit with null char temporary remplaced
cat "$corg"|tr '\0' '£'|sed -e '1 s/.*/.£/' -e 's/(£D[^)]*)£//g'|tr '£' 
'\0' > "$cnew"
icacls "$j" /restore $(cygpath -w "$cnew") || exit 1
done

This solution not complete is usable for me now. I find many pbs in cygwin 
system
 (more than 3000 in /bin /lib ...)
I am not confident to leave this problem with ACLs. Some files are concerned, 
the others not.
I want a more deterministic function for the cygwin system.
May be an upgrade of all project datas is necessary before the use of these new 
acl functionnalities.

Sorry for my english

Regards


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Issues with ACL settings after updating to the latest cygwin.dll

[Corinna Vinschen]

On Feb 10 18:17, xnor wrote:
> 
> >Which warning do you mean here?
> The "permissions out of order" one. This was not the case before, at least
> not on my installation, so I don't see how this can be called normal.

It was already the case before.  It depends on the POSIX permissions
which have to be emulated using a Windows ACL, so you don't see this all
the time.  As a funny sidenote, you'd get the exact same when using the
Interix/SFU POSIX subsystem.  It had the same POSIX vs. Windows semantics
problem to solve.

Things change.  The new Cygwin ACL handling tries to emulate POSIX ACLs
more closely than before.  The role model is what you can download from
http://wt.tuxomania.net/publications/posix.1e/download.html and what's
used on Linux, Solaris, and others.  The Linux man page on ACLs,
http://linux.die.net/man/5/acl, might be helpful, too.

> >Come on, be fair.  The new ACL handling started out early 2015, got a
> >break when I realized that it doesn't work as is, and then got a new
> >test phase starting back in September.  Except for minor bugs it seemed
> >to work rather well.  Nobody reported this effect in all the 4 months of
> >test period.  You don't actually think I wouldn't have fixed it prior
> >to the release if I had known about it, do you?
> 2.4.0-1 was released ~3 weeks ago. I had actually upgraded a few days
> earlier to a TEST version and noticed that a cygwin downloaded exe couldn't
> be executed but assumed the exe was corrupt and didn't investigate...
> Then a few days ago the same thing happened again. Now I'm here.
> 
> Anyway, clearly most users are just that: users, and not testers that will
> install and test TEST versions.

Which is a pity from the dev POV.  The test releases are created so that
people have a chance to test changes before they are officially released.
The less people test test releases, the less bugs are found prior to a
release.  It's also very simple to install a test release via setup and,
if a problem is interfering, to re-install the current release version,
ideally after reporting the problem.

> >They are not supposed to be modifiable in Explorer.  If you want to
> >change permissions on a Cygwin ACL, use chmod or setfacl.
> Is this a joke?

No.

> >> Here is the output from icacls /saveacl for some file:
> >>D:P(D;;RPWPDTRC;;;S-1-0-0)(A;;0x1f019f;;;S-1-5-21-559282050-488988736-2019639472-1001)(D;;WP;;;AU)(D;;WP;;;SY)(D;;WP;;;BA)(D;;WP;;;BU)(A;;FR;;;S-1-5-21-559282050-488988736-2019639472-513)(A;;0x1201bf;;;AU)(A;;0x1201bf;;;SY)(A;;0x1201bf;;;BA)(A;;0x1200a9;;;BU)(A;;FR;;;WD)
> >Doh, I'm sorry, but I can't read this format very well.  Can you please
> >again send the standard icacls output as well as the output from getfacl
> >of the parent dir and the created file?  I'd like to have this problem
> >fixed, but I need your help.  As I said, it works fine for me and without
> >being able to reproduce I'm somewhat at a loss.
> You can import this by putting it in a textfile and using icacls testfile
> /restore acl.txt.

Doesn't work.  First, your machine is using different SIDs of course,
so the SID entries have no meaning on my machine.  Second, even after
changing the SIDs to ones I can use locally, icacls /restore just doesn't
work for me.  It requires that the path to restore is a directory, and
even when giving it a directory, I get an error:

  CMD> icacls C:\cygwin64\home\corinna\subdir\ /restore acl.txt
  
C:\cygwin64\home\corinna\subdir\??:
 The system cannot find the file specified.
  Successfully processed 0 files; Failed processing 1 files

> As I've said before, my Windows is German. icacls output will be localized.
> Do you really want that?

My german is not that bad, all things considered.  "None" is "Kein",
"Administrators" is "Administratoren"...

> What I posted is the only portable way to share ACLs.

Given the SID problem, it's not portable.

Again, do you want me to be able to analyze the problem and, *iff* there's
a bug, fix it?  If so, please don't double guess what I'm asking for.

Please provide stock icacls output as well as getfacl output for the
parent dir in which you download the file, and for the file itself.
Don't call the Explorer GUI on the ACL, don't reorder.

> >If you don't want POSIX perms, but standard Windows perms, use the "noacl"
> >mount option.  See https://cygwin.com/cygwin-ug-net/using.html#mount-table
> I guess that is my only option right now.

If you're looking for Windows ACL semantics, it's the way to go.

&

Re: Issues with ACL settings after updating to the latest cygwin.dll

[Andrey Repin]

Greetings, xnor!

>>It is normal and was normal for at least seventeen years.
> That's a blatant lie.
> It never happened to me before, and I doubled checked this by installing 
> the older 2.3. It didn't happen before 2.4.

"Never happened to you" does not equal "wasn't the case".
Your presumptuous supposition does not count towards your credit.

>>You'd be surprized… But the actual answer is "yes".
> I actually am surprised since you seem to have undergone a sex change 
> and are now Corinna.

Or perhaps I know a little about inhabitants of this list?
A little something that tells me Corinna would have no issues reading her
mother language?

>>You weren't asked for "portable".
> I didn't talk to you. You weren't asked anything.

> I find it quite rude that you feel the need to intrude into a discussion 
> giving nonsensical know-it-all responses .. even on behalf of other 
> people.

> I'll ignore further emails from you, thanks for wasting my time.

You're welcome.


-- 
With best regards,
Andrey Repin
Thursday, February 11, 2016 02:19:26

Sorry for my terrible english...

Re[2]: Issues with ACL settings after updating to the latest cygwin.dll

[xnor]

It is normal and was normal for at least seventeen years.

That's a blatant lie.
It never happened to me before, and I doubled checked this by installing 
the older 2.3. It didn't happen before 2.4.




You'd be surprized… But the actual answer is "yes".
I actually am surprised since you seem to have undergone a sex change 
and are now Corinna.




You weren't asked for "portable".

I didn't talk to you. You weren't asked anything.

I find it quite rude that you feel the need to intrude into a discussion 
giving nonsensical know-it-all responses .. even on behalf of other 
people.


I'll ignore further emails from you, thanks for wasting my time.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Issues with ACL settings after updating to the latest cygwin.dll

[Andrey Repin]

Greetings, xnor!

>>Which warning do you mean here?
> The "permissions out of order" one. This was not the case before, at 
> least not on my installation, so I don't see how this can be called 
> normal.

It is normal and was normal for at least seventeen years.

>>Come on, be fair.  The new ACL handling started out early 2015, got a
>>break when I realized that it doesn't work as is, and then got a new
>>test phase starting back in September.  Except for minor bugs it seemed
>>to work rather well.  Nobody reported this effect in all the 4 months 
>>of
>>test period.  You don't actually think I wouldn't have fixed it prior
>>to the release if I had known about it, do you?
> 2.4.0-1 was released ~3 weeks ago. I had actually upgraded a few days 
> earlier to a TEST version and noticed that a cygwin downloaded exe 
> couldn't be executed but assumed the exe was corrupt and didn't 
> investigate...
> Then a few days ago the same thing happened again. Now I'm here.

> Anyway, clearly most users are just that: users, and not testers that 
> will install and test TEST versions.

I hope this is not a complaint? You are supposed to know what you are doing,
when installing test versions.

>>They are not supposed to be modifiable in Explorer.  If you want to
>>change permissions on a Cygwin ACL, use chmod or setfacl.
> Is this a joke?

It is a statement of the matter.

>>
>>>  Here is the output from icacls /saveacl for some file:
>>>  
>>>D:P(D;;RPWPDTRC;;;S-1-0-0)(A;;0x1f019f;;;S-1-5-21-559282050-488988736-2019639472-1001)(D;;WP;;;AU)(D;;WP;;;SY)(D;;WP;;;BA)(D;;WP;;;BU)(A;;FR;;;S-1-5-21-559282050-488988736-2019639472-513)(A;;0x1201bf;;;AU)(A;;0x1201bf;;;SY)(A;;0x1201bf;;;BA)(A;;0x1200a9;;;BU)(A;;FR;;;WD)
>>Doh, I'm sorry, but I can't read this format very well.  Can you please
>>again send the standard icacls output as well as the output from 
>>getfacl
>>of the parent dir and the created file?  I'd like to have this problem
>>fixed, but I need your help.  As I said, it works fine for me and 
>>without
>>being able to reproduce I'm somewhat at a loss.
> You can import this by putting it in a textfile and using icacls 
> testfile /restore acl.txt.
> As I've said before, my Windows is German. icacls output will be 
> localized. Do you really want that?

You'd be surprized… But the actual answer is "yes".

> What I posted is the only portable way to share ACLs.

You weren't asked for "portable".

P.S.
Please don't use gmail web interface to post to the list. Either use normal
mail cleint, or gmane.
You're breaking threading.


-- 
With best regards,
Andrey Repin
Wednesday, February 10, 2016 23:31:57

Sorry for my terrible english...

Re: Issues with ACL settings after updating to the latest cygwin.dll

[Andrey Repin]

Greetings, xnor!


>>It was always the case.
>>Permissions are NOT REQUIRED to be ordered in a specific way, but 
>>Explorer is
>>only capable of editing them in the only one way.
>>Means, Explorer is deficient. Explorer. Not Windows. Windows is 
>>perfectly
>>capable of handling the Cygwin ACL in the intended way.
> No, it really wasn't.

> The ACLs were fine until the change in the new Cygwin version. Now there 
> are 12 ACL entries, all non inherited / inheritance is broken, for each 
> file...

That's normal POSIX behavior.
If you want Windows behavior, mount your outside-Cygwin FS with noacl flag.


-- 
With best regards,
Andrey Repin
Wednesday, February 10, 2016 21:20:45

Sorry for my terrible english...


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re[2]: Issues with ACL settings after updating to the latest cygwin.dll

[xnor]

Which warning do you mean here?
The "permissions out of order" one. This was not the case before, at 
least not on my installation, so I don't see how this can be called 
normal.




Come on, be fair.  The new ACL handling started out early 2015, got a
break when I realized that it doesn't work as is, and then got a new
test phase starting back in September.  Except for minor bugs it seemed
to work rather well.  Nobody reported this effect in all the 4 months 
of

test period.  You don't actually think I wouldn't have fixed it prior
to the release if I had known about it, do you?
2.4.0-1 was released ~3 weeks ago. I had actually upgraded a few days 
earlier to a TEST version and noticed that a cygwin downloaded exe 
couldn't be executed but assumed the exe was corrupt and didn't 
investigate...

Then a few days ago the same thing happened again. Now I'm here.

Anyway, clearly most users are just that: users, and not testers that 
will install and test TEST versions.




They are not supposed to be modifiable in Explorer.  If you want to
change permissions on a Cygwin ACL, use chmod or setfacl.

Is this a joke?





 Here is the output from icacls /saveacl for some file:
 
D:P(D;;RPWPDTRC;;;S-1-0-0)(A;;0x1f019f;;;S-1-5-21-559282050-488988736-2019639472-1001)(D;;WP;;;AU)(D;;WP;;;SY)(D;;WP;;;BA)(D;;WP;;;BU)(A;;FR;;;S-1-5-21-559282050-488988736-2019639472-513)(A;;0x1201bf;;;AU)(A;;0x1201bf;;;SY)(A;;0x1201bf;;;BA)(A;;0x1200a9;;;BU)(A;;FR;;;WD)

Doh, I'm sorry, but I can't read this format very well.  Can you please
again send the standard icacls output as well as the output from 
getfacl

of the parent dir and the created file?  I'd like to have this problem
fixed, but I need your help.  As I said, it works fine for me and 
without

being able to reproduce I'm somewhat at a loss.
You can import this by putting it in a textfile and using icacls 
testfile /restore acl.txt.
As I've said before, my Windows is German. icacls output will be 
localized. Do you really want that?

What I posted is the only portable way to share ACLs.




 Here is what's "normal" for Windows if I create a file under a new 
folder on

 C: in Explorer:


If you don't want POSIX perms, but standard Windows perms, use the 
"noacl"
mount option.  See 
https://cygwin.com/cygwin-ug-net/using.html#mount-table

I guess that is my only option right now.




 Here is what I would expect:
 MyUser is in the group Administrators. Given the inherited 
permissions above

 a Windows-created file should be shown as "-rwxrwxr--+ MyUser
 Administrators"?


Sorry, can't do that, *unless* you make "Administrators" the primary
group in your user token(*).

Ok, so the group is "None". No big deal.

So what about fixing the permissions like I described?
So the permissions would be "-rwx--+ MyUser None" in Cygwin for a 
Windows-created file with default ACL.


By using the inherited default ACLs there should be at most 3 additional 
ACLs (+1 for NULL SID whatever that is doing):

- deny r/w/x for user ("MyUser")
- allow r/w/x for group ("None")
- allow r/w/x for other ("Everyone")

And leaving the inherited ones untouched, right?
But if you scroll up you will see that in my system Cygwin kills the 
inheritance and I end up with 12 new ACL entries for each file.



--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re[2]: Issues with ACL settings after updating to the latest cygwin.dll

[xnor]

It was always the case.
Permissions are NOT REQUIRED to be ordered in a specific way, but 
Explorer is

only capable of editing them in the only one way.
Means, Explorer is deficient. Explorer. Not Windows. Windows is 
perfectly

capable of handling the Cygwin ACL in the intended way.

No, it really wasn't.

The ACLs were fine until the change in the new Cygwin version. Now there 
are 12 ACL entries, all non inherited / inheritance is broken, for each 
file...


Also, I always ways able to change ACLs through Explorer without 
warnings, which I need to do from time to time.


I'm sorry but all of this can be summed up as bad design.


I've explained what ACLs should be added by Cygwin in a related message. 
By making use of default, inherited ACLs, at most 3 (+1 for whatever 
NULL SID is doing ...) are needed. At least I see no reason why there 
should be such a bloat.


Besides, if cygwin set ACLs properly on the root folder this could be 
reduced to 0 additional non-inherited ACLs for many files.



--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Issues with ACL settings after updating to the latest cygwin.dll

[Corinna Vinschen]

On Feb 10 12:55, Corinna Vinschen wrote:
> On Feb  9 20:53, xnor wrote:
> > Here is what I would expect:
> > MyUser is in the group Administrators. Given the inherited permissions above
> > a Windows-created file should be shown as "-rwxrwxr--+ MyUser
> > Administrators"?
> 
> Sorry, can't do that, *unless* you make "Administrators" the primary
> group in your user token(*).  Even though your account is *member* of
> the Administrators group, the group is *never* your primary group per
> Windows.  All local accounts, independently of their group memberships,
> have the group "None" as their primary group.  That's how Windows works,
> and that hasn't changed since at least NT4.
> 
> Unless, of course, if you use a so-called "Windows account", one of
> those accounts which you login with using your email address (was that
> introduced with Windows 8?  I'm not sure).  In that case, the primary
> group in your user token is set to your user account itself.  So your
> primary group SID is your own user SID.  Duh!
> 
> 
> Corinna
> 
> (*) There *is* a way to do that, but only inside Cygwin, see
> https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-passwdinfo

Oh, and if it's not clear how this works under the hood, it's like this:

The Windows user token contains a couple of SID entries:

- The "user" SID
- The "owner" SID   (user and owner are not necessarily the same,
 but, never mind)
- The primary group SID (which, it has to be said, is meaningless
 in the Windows context and only kept for
 POSIX compatibility)
- A list of group SIDs the user is member in.

For a local account, the primary group SID is set to "None", the local
group with RID 513.  For domain accounts this is typically the group
"Domain Users", the domain account with RID 513 (hmm...)

However, every process is allowed to switch the primary group entry of
its user token to *any* group mentioned in the group list, *or* even to
its user or owner SID.  If you use the aforementioned method to change
the primary group, what happens is that the first Cygwin process in a
process chain changes the primary group in its user token.  If the new
group is in the token's group list, this will work.

Child processes inherit the user token from their parent process, so
there's no reason to change the primary group again in a process tree.
Since that's a Windows property, this also works for non-Cygwin child
processes.

With the Administrators group there's a complication.  If you're running
a normal shell, it's running under UAC control.  UAC restricts the user
token of an admin user so that the admins group in the token group list
is "crippled":  The admins SID is still in the list, but with a flag
"DENY ONLY".  You're kind of not in the Administrators group anymore.
Only if an access check is performed, and the Admins group is denied
access to some object, this membership kicks in and denies the access.


HTH,
Corinna

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


signature.asc
Description: PGP signature