Re: Howto to backup and restore windows ACL?

2024-02-29 Thread 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?

2024-02-28 Thread 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?

2023-04-07 Thread 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?

2023-04-07 Thread 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

2023-02-21 Thread 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: ACL

2023-02-21 Thread Thomas Wolff via Cygwin-apps




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

Hi,


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

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


ACL

2023-02-21 Thread Jonathan Chapman-Moore via Cygwin-apps
Hi,


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

http://savannah.nongnu.org/projects/acl

Thanks,

Jonathan Moore


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

2021-05-25 Thread 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

2021-05-25 Thread 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

2021-05-25 Thread 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


[PATCH cygport] Remove all extended ACL entries of ${workdir}, first.

2021-01-10 Thread Lemures Lemniscati via Cygwin-apps
Hi!

This is another patch for cygport: 

In lib/src_prep.cygpart/__mkdirs(),
remove all extended ACL entries of ${workdir}, first,
as a fool-proof (e.g., in case file permission tests are required,
or in case file permission under ${D} would be contaminated).


I encounterd a case (cmake) in which a file-permission test failed, but
it passed by using `setfacl -b`.


I think this patch would not harm.


Regards,

Lem


cygport-setfacl--remove-all.patch
Description: Binary data


Fwd: Fwd: Switching to posix with no acl

2020-11-14 Thread 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

2020-11-14 Thread 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

2020-11-14 Thread 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

2020-11-14 Thread 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

2020-11-13 Thread 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

2020-10-25 Thread 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

2020-10-24 Thread 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

2020-10-24 Thread 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

2020-10-24 Thread 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

2020-10-23 Thread 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

2020-10-23 Thread 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

2020-10-23 Thread 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

2020-10-23 Thread 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

2020-10-23 Thread 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

2020-10-23 Thread 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

2020-10-23 Thread 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: [PATCH] Fix incorrect sign-extension of pointer in 32-bit acl __to_entry

2020-07-13 Thread Corinna Vinschen
On Jul 10 18:31, David Allsopp via Cygwin-patches wrote:
> Corinna Vinschen wrote:
> > On Jul 10 15:22, David Allsopp via Cygwin-patches wrote:
> > > Corinna Vinschen wrote:
> > > > On Jul  9 20:30, David Allsopp via Cygwin-patches wrote:
> > > > > I have some code where the acl_t returned by get_file_acl is
> > > > > allocated at 0x80038248. As a result the acl_entry_t generated by
> > > > > acl_get_entry has an "index" of -1, since the pointer was sign-
> > extended to 64-bits.
> > > > >
> > > > > My fix is trivial and simply casts the pointer to uintptr_t first.
> > > >
> > > > Pushed.  I still don't quite understand what the compiler is
> > > > thinking there, sign-extending a pointer when casted to an unsigend
> > > > int type, but your patch works, so all is well, I guess.
> > >
> > > Thank you - it is indeed hard to imagine when you'd ever want that
> > behaviour!
> > 
> > I wonder if this is a bug in x86 gcc... Jon?
> 
> I put it to our C gurus in the OCaml team - one (who has also written
> a formally verified C compiler which on purpose 0-extends in this
> case) observed that GCC does the same for ARM32 and another (who has
> occasionally delighted in abusing language memory models to concoct
> highly bizarre, but legal, abuses of undefined behaviour) found
> https://gcc.gnu.org/onlinedocs/gcc/Arrays-and-pointers-implementation.html...

"Bizarre" is the right description here :)


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer


RE: [PATCH] Fix incorrect sign-extension of pointer in 32-bit acl __to_entry

2020-07-10 Thread David Allsopp via Cygwin-patches
Corinna Vinschen wrote:
> On Jul 10 15:22, David Allsopp via Cygwin-patches wrote:
> > Corinna Vinschen wrote:
> > > On Jul  9 20:30, David Allsopp via Cygwin-patches wrote:
> > > > I have some code where the acl_t returned by get_file_acl is
> > > > allocated at 0x80038248. As a result the acl_entry_t generated by
> > > > acl_get_entry has an "index" of -1, since the pointer was sign-
> extended to 64-bits.
> > > >
> > > > My fix is trivial and simply casts the pointer to uintptr_t first.
> > >
> > > Pushed.  I still don't quite understand what the compiler is
> > > thinking there, sign-extending a pointer when casted to an unsigend
> > > int type, but your patch works, so all is well, I guess.
> >
> > Thank you - it is indeed hard to imagine when you'd ever want that
> behaviour!
> 
> I wonder if this is a bug in x86 gcc... Jon?

I put it to our C gurus in the OCaml team - one (who has also written a 
formally verified C compiler which on purpose 0-extends in this case) observed 
that GCC does the same for ARM32 and another (who has occasionally delighted in 
abusing language memory models to concoct highly bizarre, but legal, abuses of 
undefined behaviour) found 
https://gcc.gnu.org/onlinedocs/gcc/Arrays-and-pointers-implementation.html... 
although the Git history for GCC makes it fairly clear that this behaviour is 
retrospectively documented[1][2]!


David


[1] https://github.com/gcc-mirror/gcc/commit/cbf4c36fa373
[2] https://github.com/gcc-mirror/gcc/commit/58f4de4f271c


Re: [PATCH] Fix incorrect sign-extension of pointer in 32-bit acl __to_entry

2020-07-10 Thread Corinna Vinschen
On Jul 10 15:22, David Allsopp via Cygwin-patches wrote:
> Corinna Vinschen wrote:
> > On Jul  9 20:30, David Allsopp via Cygwin-patches wrote:
> > > I have some code where the acl_t returned by get_file_acl is allocated
> > > at 0x80038248. As a result the acl_entry_t generated by acl_get_entry
> > > has an "index" of -1, since the pointer was sign-extended to 64-bits.
> > >
> > > My fix is trivial and simply casts the pointer to uintptr_t first.
> > 
> > Pushed.  I still don't quite understand what the compiler is thinking
> > there, sign-extending a pointer when casted to an unsigend int type, but
> > your patch works, so all is well, I guess.
> 
> Thank you - it is indeed hard to imagine when you'd ever want that behaviour!

I wonder if this is a bug in x86 gcc... Jon?

> Would it be possible to have a snapshot with it, just for continuous
> integration servers which need the fix, please?

Sure, done.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer


RE: [PATCH] Fix incorrect sign-extension of pointer in 32-bit acl __to_entry

2020-07-10 Thread David Allsopp via Cygwin-patches
Corinna Vinschen wrote:
> On Jul  9 20:30, David Allsopp via Cygwin-patches wrote:
> > I have some code where the acl_t returned by get_file_acl is allocated
> > at 0x80038248. As a result the acl_entry_t generated by acl_get_entry
> > has an "index" of -1, since the pointer was sign-extended to 64-bits.
> >
> > My fix is trivial and simply casts the pointer to uintptr_t first.
> 
> Pushed.  I still don't quite understand what the compiler is thinking
> there, sign-extending a pointer when casted to an unsigend int type, but
> your patch works, so all is well, I guess.

Thank you - it is indeed hard to imagine when you'd ever want that behaviour!

Would it be possible to have a snapshot with it, just for continuous 
integration servers which need the fix, please?


David


Re: [PATCH] Fix incorrect sign-extension of pointer in 32-bit acl __to_entry

2020-07-10 Thread Corinna Vinschen
On Jul  9 20:30, David Allsopp via Cygwin-patches wrote:
> I have some code where the acl_t returned by get_file_acl is allocated at
> 0x80038248. As a result the acl_entry_t generated by acl_get_entry has an
> "index" of -1, since the pointer was sign-extended to 64-bits.
> 
> My fix is trivial and simply casts the pointer to uintptr_t first.

Pushed.  I still don't quite understand what the compiler is thinking
there, sign-extending a pointer when casted to an unsigend int type,
but your patch works, so all is well, I guess.


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer


[PATCH] Fix incorrect sign-extension of pointer in 32-bit acl __to_entry

2020-07-09 Thread David Allsopp via Cygwin-patches
I have some code where the acl_t returned by get_file_acl is allocated at
0x80038248. As a result the acl_entry_t generated by acl_get_entry has an
"index" of -1, since the pointer was sign-extended to 64-bits.

My fix is trivial and simply casts the pointer to uintptr_t first.

All best,


David


0001-Fix-invalid-acl_entry_t-on-32-bit-Cygwin.patch
Description: Binary data


Re: Files and folders created with invalid ACL

2020-06-22 Thread 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

2020-06-22 Thread 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

2020-06-22 Thread 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

2020-06-22 Thread 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

2020-06-22 Thread 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

2020-06-21 Thread 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

2020-06-21 Thread 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

2020-06-21 Thread 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

2020-06-21 Thread 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?

2020-03-27 Thread 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?

2020-03-27 Thread 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?

2020-03-27 Thread 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?

2020-03-26 Thread 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?

2020-03-26 Thread 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


[newlib-cygwin] Cygwin: symlink/mknod: fix ACL handling

2020-01-28 Thread Corinna Vinschen
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=4bfa93f1a00a09e4fb3bccea334ba22e4c05c3d6

commit 4bfa93f1a00a09e4fb3bccea334ba22e4c05c3d6
Author: Corinna Vinschen 
Date:   Tue Jan 28 17:57:50 2020 +0100

Cygwin: symlink/mknod: fix ACL handling

mknod32 actually creates a path_conv, just to call mknod_worker
with a win32 path.  This doesn't only require to create path_conv
twice, it also breaks permissions on filesystems supporting ACLs.

Fix this by passing the path_conv created in the caller down to
symlink_worker.  Also, while at it, simplify the handling of trailing
slashes and move it out of symlink_worker.  Especially use the
new PC_SYM_NOFOLLOW_DIR flag to avoid fiddeling with creating
a new path copy without the trailing slash.

Signed-off-by: Corinna Vinschen 

Diff:
---
 winsup/cygwin/path.cc | 69 +++
 winsup/cygwin/path.h  |  2 +-
 winsup/cygwin/syscalls.cc | 41 +++-
 3 files changed, 57 insertions(+), 55 deletions(-)

diff --git a/winsup/cygwin/path.cc b/winsup/cygwin/path.cc
index 5ebbddf..142a739 100644
--- a/winsup/cygwin/path.cc
+++ b/winsup/cygwin/path.cc
@@ -1674,7 +1674,34 @@ conv_path_list (const char *src, char *dst, size_t size,
 extern "C" int
 symlink (const char *oldpath, const char *newpath)
 {
-  return symlink_worker (oldpath, newpath, false);
+  path_conv win32_newpath;
+
+  __try
+{
+  if (!*oldpath || !*newpath)
+   {
+ set_errno (ENOENT);
+ __leave;
+   }
+
+  /* Trailing dirsep is a no-no, only errno differs. */
+  bool has_trailing_dirsep = isdirsep (newpath[strlen (newpath) - 1]);
+  win32_newpath.check (newpath,
+  PC_SYM_NOFOLLOW | PC_SYM_NOFOLLOW_DIR | PC_POSIX,
+  stat_suffixes);
+
+  if (win32_newpath.error || has_trailing_dirsep)
+   {
+ set_errno (win32_newpath.error ?:
+win32_newpath.exists () ? EEXIST : ENOENT);
+ __leave;
+   }
+
+  return symlink_worker (oldpath, win32_newpath, false);
+}
+  __except (EFAULT) {}
+  __endtry
+  return -1;
 }
 
 static int
@@ -1846,15 +1873,12 @@ symlink_native (const char *oldpath, path_conv 
_newpath)
 }
 
 int
-symlink_worker (const char *oldpath, const char *newpath, bool isdevice)
+symlink_worker (const char *oldpath, path_conv _newpath, bool isdevice)
 {
   int res = -1;
   size_t len;
-  path_conv win32_newpath;
   char *buf, *cp;
   tmp_pathbuf tp;
-  unsigned check_opt;
-  bool has_trailing_dirsep = false;
   winsym_t wsym_type;
 
   /* POSIX says that empty 'newpath' is invalid input while empty
@@ -1862,31 +1886,12 @@ symlink_worker (const char *oldpath, const char 
*newpath, bool isdevice)
  symlink contents point to existing filesystem object */
   __try
 {
-  if (!*oldpath || !*newpath)
-   {
- set_errno (ENOENT);
- __leave;
-   }
-
   if (strlen (oldpath) > SYMLINK_MAX)
{
  set_errno (ENAMETOOLONG);
  __leave;
}
 
-  /* Trailing dirsep is a no-no. */
-  len = strlen (newpath);
-  has_trailing_dirsep = isdirsep (newpath[len - 1]);
-  if (has_trailing_dirsep)
-   {
- newpath = strdup (newpath);
- ((char *) newpath)[len - 1] = '\0';
-   }
-
-  check_opt = PC_SYM_NOFOLLOW | PC_POSIX | (isdevice ? PC_NOWARN : 0);
-  /* We need the normalized full path below. */
-  win32_newpath.check (newpath, check_opt, stat_suffixes);
-
   /* Default symlink type is determined by global allow_winsymlinks
 variable.  Device files are always shortcuts. */
   wsym_type = isdevice ? WSYM_lnk : allow_winsymlinks;
@@ -1910,8 +1915,9 @@ symlink_worker (const char *oldpath, const char *newpath, 
bool isdevice)
  && (isdevice || !win32_newpath.fs_is_nfs ()))
{
  char *newplnk = tp.c_get ();
- stpcpy (stpcpy (newplnk, newpath), ".lnk");
- win32_newpath.check (newplnk, check_opt);
+ stpcpy (stpcpy (newplnk, win32_newpath.get_posix ()), ".lnk");
+ win32_newpath.check (newplnk, PC_SYM_NOFOLLOW | PC_POSIX
+   | (isdevice ? PC_NOWARN : 0));
}
 
   if (win32_newpath.error)
@@ -1929,11 +1935,6 @@ symlink_worker (const char *oldpath, const char 
*newpath, bool isdevice)
  set_errno (EEXIST);
  __leave;
}
-  if (has_trailing_dirsep && !win32_newpath.exists ())
-   {
- set_errno (ENOENT);
- __leave;
-   }
 
   /* Handle NFS and native symlinks in their own functions. */
   switch (wsym_type)
@@ -2189,9 +2190,7 @@ symlink_worker (const char *oldpath, const char *newpath, 
bool isdevice)
   __except (EFAULT) {}
   __endtry
   syscall_printf ("%d = symlink_worker(%s, %s, %d)",
- res, oldpath, newpa

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

2019-12-29 Thread 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

2019-12-28 Thread 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

2019-12-28 Thread 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

2019-12-28 Thread 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

2019-12-24 Thread 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

2019-12-23 Thread 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

2019-12-22 Thread 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

2019-12-21 Thread 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

2019-12-21 Thread 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)

2019-06-06 Thread 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

2019-06-04 Thread 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

2019-06-04 Thread 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

2019-06-04 Thread 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

2019-06-04 Thread 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

2019-06-04 Thread 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

2019-06-04 Thread 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

2019-06-04 Thread 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



[newlib-cygwin] Cygwin: acls: allow converting empty acl to text

2019-03-13 Thread Corinna Vinschen
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=004d8adfa27232067aa67c2eb9aba0d29a11b2fd

commit 004d8adfa27232067aa67c2eb9aba0d29a11b2fd
Author: Corinna Vinschen 
Date:   Wed Mar 13 12:06:48 2019 +0100

Cygwin: acls: allow converting empty acl to text

Signed-off-by: Corinna Vinschen 

Diff:
---
 winsup/cygwin/release/3.0.4 | 3 +++
 winsup/cygwin/sec_acl.cc| 4 ++--
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/winsup/cygwin/release/3.0.4 b/winsup/cygwin/release/3.0.4
index e6632f4..eeed283 100644
--- a/winsup/cygwin/release/3.0.4
+++ b/winsup/cygwin/release/3.0.4
@@ -14,3 +14,6 @@ Bug Fixes
 
 - Fix access to process list
   Addresses: https://cygwin.com/ml/cygwin/2019-03/msg00253.html
+
+- Fix acl_to_text/acl_to_any_text returning EINVAL on empty acl
+  Addresses: https://cygwin.com/ml/cygwin/2019-03/msg00157.html
diff --git a/winsup/cygwin/sec_acl.cc b/winsup/cygwin/sec_acl.cc
index ce7910e..933bfa6 100644
--- a/winsup/cygwin/sec_acl.cc
+++ b/winsup/cygwin/sec_acl.cc
@@ -1638,8 +1638,8 @@ char *
 __acltotext (aclent_t *aclbufp, int aclcnt, const char *prefix, char separator,
 int options)
 {
-  if (!aclbufp || aclcnt < 1 || aclcnt > MAX_ACL_ENTRIES
-  || aclsort32 (aclcnt, 0, aclbufp))
+  if (!aclbufp || aclcnt < 0 || aclcnt > MAX_ACL_ENTRIES
+  || (aclcnt > 0 && aclsort32 (aclcnt, 0, aclbufp)))
 {
   set_errno (EINVAL);
   return NULL;


Re: continued acl problems

2018-09-07 Thread 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

2018-09-07 Thread 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

2018-09-07 Thread 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

2018-09-07 Thread 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



[newlib-cygwin] Cygwin: add release note for previous ACL changes

2018-08-27 Thread Corinna Vinschen
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=fc8aaa40fed0a835520d0071da459c9bb925ffc5

commit fc8aaa40fed0a835520d0071da459c9bb925ffc5
Author: Corinna Vinschen 
Date:   Mon Aug 27 18:30:59 2018 +0200

Cygwin: add release note for previous ACL changes

Signed-off-by: Corinna Vinschen 

Diff:
---
 winsup/cygwin/release/2.11.0 | 4 
 1 file changed, 4 insertions(+)

diff --git a/winsup/cygwin/release/2.11.0 b/winsup/cygwin/release/2.11.0
index 6ffe3f6..8f308c8 100644
--- a/winsup/cygwin/release/2.11.0
+++ b/winsup/cygwin/release/2.11.0
@@ -74,3 +74,7 @@ Bug Fixes
 
 - Fix memory allocation values in /proc//status and /proc//statm.
   Addresses: https://cygwin.com/ml/cygwin/2018-08/msg00223.html
+
+- Fix handling of unknown accounts in file ACLs.  Add name->SID
+  conversion for (most) self-constructed account names.
+  Addresses: https://cygwin.com/ml/cygwin/2018-08/msg00295.html


[newlib-cygwin] Cygwin: don't return valid acl entry type for unknown SID

2018-08-27 Thread Corinna Vinschen
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=fcfcc288c4d3e9ad3bca4d0c9dd79ee1c88a99f9

commit fcfcc288c4d3e9ad3bca4d0c9dd79ee1c88a99f9
Author: Corinna Vinschen 
Date:   Mon Aug 27 13:30:55 2018 +0200

Cygwin: don't return valid acl entry type for unknown SID

cygpsid::get_id neglects to set the type to 0 (ACL_UNDEFINED_TAG
in POSIX speak) if the SID can not be translated into a valid
uid or gid.  This in turn leads to incorrect handling of uid/gid -1
entries.

Fix this by setting type to 0 if the id is unknown.

Signed-off-by: Corinna Vinschen 

Diff:
---
 winsup/cygwin/sec_helper.cc | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/winsup/cygwin/sec_helper.cc b/winsup/cygwin/sec_helper.cc
index a1d8cba..373b1df 100644
--- a/winsup/cygwin/sec_helper.cc
+++ b/winsup/cygwin/sec_helper.cc
@@ -169,10 +169,16 @@ cygpsid::get_id (BOOL search_grp, int *type, cyg_ldap 
*pldap)
}
   else if ((pw = internal_getpwsid (*this, pldap)))
id = pw->pw_uid;
-  if (id != ILLEGAL_UID && type)
-   *type = USER;
+  if (id != ILLEGAL_UID)
+   {
+ if (type)
+   *type = USER;
+ return id;
+   }
 }
-  return id;
+  if (type)
+*type = 0; /* undefined type */
+  return ILLEGAL_UID;
 }
 
 PWCHAR


Re: gettext - acl tests - cygwin specific code path

2018-08-23 Thread 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

2018-08-22 Thread 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_DATA

Re: gettext - acl tests - cygwin specific code path

2018-08-22 Thread 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

2018-08-22 Thread 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

2018-08-22 Thread 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

2018-08-22 Thread 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

2018-08-21 Thread 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

2018-08-21 Thread 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

2018-08-21 Thread 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

2018-08-21 Thread 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

2018-08-21 Thread 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

2018-08-06 Thread 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

2018-08-06 Thread 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

2018-08-06 Thread 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

2018-08-06 Thread 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

2018-08-05 Thread 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

2018-08-05 Thread 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

2018-08-05 Thread 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

2018-08-04 Thread 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

2018-08-04 Thread 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

2018-08-04 Thread 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

2017-07-22 Thread 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

2017-07-22 Thread 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: network installation access rights/ACL issues

2016-07-13 Thread Corinna Vinschen
On Jul  9 07:39, Thomas Wolff wrote:
> Hi Corinna,
> any ideas about this network installation problem? I sent the requested ACL
> infos:
> https://cygwin.com/ml/cygwin-apps/2016-06/msg00084.html

I looked at the ACLs but I don't see anything weird, sorry.  Somebody
would have to debug this in the problematic environment.


Corinna

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


signature.asc
Description: PGP signature


network installation access rights/ACL issues

2016-07-08 Thread Thomas Wolff

Hi Corinna,
any ideas about this network installation problem? I sent the requested 
ACL infos:

https://cygwin.com/ml/cygwin-apps/2016-06/msg00084.html
I'll be in that lab again on Monday, in case you may ask for further 
diagnostics.

Thomas


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

2016-05-31 Thread 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

2016-05-30 Thread 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

2016-05-30 Thread 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


  1   2   3   4   >