From: John Ruckstuhl <john.ruckstuhl@gmail.com>
To: cygwin@cygwin.com
Subject: cygwin utils can access directory and its contents, but W10 utils claim to have no access, why?
Date: Sun, 21 Jan 2024 22:18:20 -0800 [thread overview]
Message-ID: <CAOBROv1Jgj1cZ6nL64Y=rYRR5cvd8VRw3XH0xD4E57c_=MKU=w@mail.gmail.com> (raw)
I am seeing a weird phenomenon, hopefully someone can illuminate and teach.
Or point me to an archived thread.
I have some folders that Cygwin utils can readily access,
but W10 utils claim to have no access to.
It feels as if
* the Cygwin utils try to do what they are commanded to do, and it's
up to the OS to refuse if the ACLs are insufficient.
* the W10 utils are written to decline to attempt access, due to some
convention or gentlemen's agreement (built into some API?).
But wouldn't that lead Windows users to a false sense of protection, a
false sense of security?
Environment
* Cygwin 3.4.9-1 on W10. 64-bit.
* UAC is not active (based on EnableLUA=0 at boot)
I have a 3rd-party program “yabba” that many different users run (on the
same shared PC).
It leaves behind a “temporary” dir (under
C:/Users/username/AppData/Local/Temp), each time it’s run.
Many times per day.
These dirs are approx. 1000 files and 20 MB.
The 3rd-party program is an exe-file compiled with pyinstaller.
It unpacks a python script and a python interpreter, and runs the python
script.
But in our workflow, we usually terminate the execution brutally, so the
pyinstaller cleanup does not happen, leaving the 20 MB behind.
I want Bob, a member of the local group Administrators, to remove these folders.
For example, ordinary user Alice runs yabba a couple of times and leaves
behind 20 MB in each of
C:/Users/Alice/AppData/Local/Temp/_MEI21002
C:/Users/Alice/AppData/Local/Temp/_MEI21282
Now for Local Administrator Bob, no impediment seeing these two dirs...
$ cd C\:/Users/Alice/AppData/Local/Temp
$ D1=_MEI21002
$ D2=_MEI21282
$ du -sh $D1 $D2
21M _MEI21002
21M _MEI21282
$ for D in $D1 $D2; do printf "%s\t%s\n" $D "$(find "$D" -mindepth
1 -type d -printf "dirs\n" -o -printf "files\n" | sort | uniq -c |
paste - -)"; done
_MEI21002 34 dirs 940 files
_MEI21282 33 dirs 929 files
$ getfacl $D1 $D2
# file: _MEI21002
# owner: Alice
# group: Domain Users
user::rwx
group::---
group:OWNER RIGHTS:rwx
mask::rwx
other::---
# file: _MEI21282
# owner: Alice
# group: Domain Users
user::rwx
group::---
group:OWNER RIGHTS:rwx
mask::rwx
other::---
And (for Local Administrator Bob) no impediment to removing them, for example,
$ rm -r _MEI21282
(success!)
BUT Windows utils run by Bob the Administrator on the remaining dir
are blocked, like this
(cmd, "Run as administrator"):
C:\Users\Alice\AppData\Local\Temp>dir _MEI21002
Volume in drive C is OSDisk
Volume Serial Number is 581C-10F2
Directory of C:\Users\Alice\AppData\Local\Temp\_MEI21002
File Not Found
C:\Users\Alice\AppData\Local\Temp>icacls _MEI21002
_MEI21002: Access is denied.
Successfully processed 0 files; Failed processing 1 files
As a consequence, Windows utils run by Bob the Administrator cannot
delete Alice's directory. Until they do a takeown.
The first try to delete fails:
C:\Users\Alice\AppData\Local\Temp>del /S /Q _MEI21002
Could Not Find C:\Users\Alice\AppData\Local\Temp\_MEI21002\*
But a takeown succeeds
C:\Users\Alice\AppData\Local\Temp>takeown /A /F _MEI21002 /R /D Y
Now icacls has access
C:\Users\Alice\AppData\Local\Temp>icacls _MEI21002
_MEI21002 BUILTIN\Administrators:(OI)(IO)(F)
BUILTIN\Administrators:(CI)(F)
Successfully processed 1 files; Failed processing 0 files
And the second try to delete succeeds
C:\Users\Alice\AppData\Local\Temp>del /S /Q _MEI21002
In summary, why is it that Bob the Administrator can Cygwin "rm.exe" to
delete these folders without taking ownership, but to delete with
Windows utils, he needs to take ownership first?
Thanks for teaching,
John Ruckstuhl
next reply other threads:[~2024-01-22 6:18 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-22 6:18 John Ruckstuhl [this message]
2024-01-22 7:33 ` Brian Inglis
2024-01-22 9:48 ` Corinna Vinschen
2024-01-22 18:59 ` John Ruckstuhl
2024-04-03 2:07 ` John Ruckstuhl
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAOBROv1Jgj1cZ6nL64Y=rYRR5cvd8VRw3XH0xD4E57c_=MKU=w@mail.gmail.com' \
--to=john.ruckstuhl@gmail.com \
--cc=cygwin@cygwin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).