X-Recipient:	archive-cygwin AT delorie DOT com
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org 1329E3858409
DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1705908860;
	bh=t40KyEUh1DRkeAHEUzfSxs3l2gVFToNeoJGKDOzbQPE=;
	h=Date:Subject:To:References:In-Reply-To:List-Id:List-Unsubscribe:
	List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc:
	From;
	b=DbLXirhdVDMtkhDSf+ihXS2apga0B6lJHqMxRMIOataS4QldtMQ40zMP3PeXfsr2u
	d/xJUZR306nWjWd/J3jwWD9B+iSFCXsGKOj8lDv9DmoGfoI0NSJdKQmEBVZKgLl1qh
	Y/z01fUR8wNgvL/xU2j+lu+BA4EiOTTFsNGZm1Rg=
X-Original-To:	cygwin AT cygwin DOT com
Delivered-To:	cygwin AT cygwin DOT com
DMARC-Filter:	OpenDMARC Filter v1.4.2 sourceware.org E13B93858D3C
ARC-Filter:	OpenARC Filter v1.0.0 sourceware.org E13B93858D3C
ARC-Seal:	i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1705908837; cv=none;
	b=oIO3Lq4pdHMOkc+zvRLvmYQtvE/Y9bSDibj3loj+dcydXW1P4hKF2M8NXVMEwj5XYwBTQzjc/DeqGaU4vchKB87tKJ/kuPPR55zK5bC03IzolsqVSd4OIa73OasDPp0fGp44SLw/jgeOSJS0HdoADKIflkl1CczfBbxPl7lzXqM=
ARC-Message-Signature:	i=1; a=rsa-sha256; d=sourceware.org; s=key;
	t=1705908837; c=relaxed/simple;
	bh=zQ3n9eJkL8owsrnPBoBIIaYymYKeqCXad1wlZP1mGoc=;
	h=Message-ID:Date:MIME-Version:Subject:To:From;
	b=eMlQuaSklWKRS5KKVhJtLNFB2mDtFvBc//EjjlpIryNBaD8F+NRWI+UyuSREA16yV/OgbRvvwBElaimacSKWikpgQw7QUo6mBkfTs3xwSlLeN5Rez5i34JhxsGhchBwWcbAvoDhvrUFHYW7SqcuLpp5wbmn614jLddVq38FYZKY=
ARC-Authentication-Results:	i=1; server2.sourceware.org
Message-ID:	<a8bb8fae-b629-48c1-966d-f30228cb0c89@SystematicSW.ab.ca>
Date:	Mon, 22 Jan 2024 00:33:52 -0700
MIME-Version:	1.0
User-Agent:	Mozilla Thunderbird
Subject:	Re: cygwin utils can access directory and its contents, but W10 utils
	claim to have no access, why?
To:	cygwin AT cygwin DOT com
References:	<CAOBROv1Jgj1cZ6nL64Y=rYRR5cvd8VRw3XH0xD4E57c_=MKU=w AT mail DOT gmail DOT com>
Organization:	Systematic Software
In-Reply-To:	<CAOBROv1Jgj1cZ6nL64Y=rYRR5cvd8VRw3XH0xD4E57c_=MKU=w@mail.gmail.com>
X-Rspamd-Queue-Id:	03D7E6000F
X-Spam-Status:	No, score=-1.2 required=5.0 tests=BAYES_00, CLAIM_SUBJECT,
	KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL,
	SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE,
	UNPARSEABLE_RELAY autolearn=no autolearn_force=no version=3.4.6
X-Rspamd-Server:	rspamout02
X-Stat-Signature:	niuf1hy6etmte8i148oxjycj3nbwk3s9
X-Session-Marker:	427269616E2E496E676C69734053797374656D6174696353572E61622E6361
X-Session-ID:	U2FsdGVkX1/BH5FwTxrwxV/AeQke7FaNFwl+WKygd2U=
X-HE-Tag:	1705908832-617780
X-HE-Meta:	U2FsdGVkX19WzWwyCYM5Er9cc3AXsGf/3Deal1J/7q5ueDzLIQiM9INy/VfdKl4/7lTfhZohUFajmKuh9iD0BP3R5OM2futlrYb4/GAZ0+MPe7/GMibTs8CLmREGVehFs1itzAytRA041cgEtdibjf2aIy6ZulWBpLIvgJTyM2aZ2+FS57xAhB6EThG3qKPOzCGqdqZI08sTOWM+NV45I/td7XxTnY3YLMyECZQBCSINenxX/bWKLHFErs8SJ7B5c8SoIekFW1WL43A8J7Sc9Ogg7dBuYHKHXjKSsGWNj4xrYn6IXP+CmpaRehNY5iT+UMFwlZZYzS+TmVQeL3LQFYDbTdVodZY8
X-Spam-Checker-Version:	SpamAssassin 3.4.6 (2021-04-09) on
	server2.sourceware.org
X-BeenThere:	cygwin AT cygwin DOT com
X-Mailman-Version:	2.1.30
List-Id:	General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Unsubscribe:	<https://cygwin.com/mailman/options/cygwin>,
	<mailto:cygwin-request AT cygwin DOT com?subject=unsubscribe>
List-Archive:	<https://cygwin.com/pipermail/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe:	<https://cygwin.com/mailman/listinfo/cygwin>,
	<mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
From:	Brian Inglis via Cygwin <cygwin AT cygwin DOT com>
Reply-To:	cygwin AT cygwin DOT com
Cc:	Brian Inglis <Brian DOT Inglis AT SystematicSW DOT ab DOT ca>
Errors-To:	cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com
Sender:	"Cygwin" <cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com>
X-MIME-Autoconverted:	from base64 to 8bit by delorie.com id 40M7YLQJ015450

On 2024-01-21 23:18, John Ruckstuhl via Cygwin wrote:
> 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?

I normally find the problem is that a directory has no useful Windows DACLs 
defined, so directories or files created in it by Cygwin programs are not 
accessible to Windows programs.
It seems to me, that when Cygwin creates directories or files in those 
directories, they have no Windows ACLs defaulted, but they seem to look fine to 
Cygwin's assumed POSIX permissions, as if on FAT drives?
Better explanations would be welcome.

For directories, run:

	$ lsattr -adl 	$D
	$ ls -adlL	$D
	$ getfacl	$D
	$ icalcs "$(cygpath -m "$D")"

and for files, skip lsattr.

This should show you all the views of permissions you need to figure out the issue.

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

- Raw text -