X-Recipient:	archive-cygwin AT delorie DOT com
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org 5C1FA3857BB7
DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1705904335;
	bh=dVHCiv6DIn15k7eZT2+PQjDcVvSGizcSvTCxF7yz2Dk=;
	h=Date:Subject:To:List-Id:List-Unsubscribe:List-Archive:List-Post:
	List-Help:List-Subscribe:From:Reply-To:From;
	b=MsU1uDiWeK7CGVV4awT33X1umq53QJ9TrPKT4dwPaCk6w2SQWFfApUSIiSnJGoLWE
	baI6XtojEjylhfMCL1Jyl8YTAWrNVvkuG1XOlc5Yb/K9u6cCQaP9Rm2JPtlEqPUxSJ
	VQVndkXvpU/Z4IpzyIBPxkcp2NHdptlGa4zpyh64=
X-Original-To:	cygwin AT cygwin DOT com
Delivered-To:	cygwin AT cygwin DOT com
DMARC-Filter:	OpenDMARC Filter v1.4.2 sourceware.org 930BE3858429
ARC-Filter:	OpenARC Filter v1.0.0 sourceware.org 930BE3858429
ARC-Seal:	i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1705904315; cv=none;
	b=p9+xFhIPPiVhxoOM3cO8J5Ilgg7nK1mcr+qb8tAs91DDsMPfj7r0t4yri+EwdKhMp4ty3OsZtdYf6SAkHXqpvKCv6kjgFxzEq9H2t/y/cTYwQQ4q2FHl0270euw21UYjfx2p7Jrg+MmIN1BGd6aFzW/m3hwsdhAkYbpUKPY0HGc=
ARC-Message-Signature:	i=1; a=rsa-sha256; d=sourceware.org; s=key;
	t=1705904315; c=relaxed/simple;
	bh=34eEkAWyNxQZE2cqLWgUN0xYucunaBx3mJ90FEPEoEE=;
	h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To;
	b=DnH9rhDaIeL6tC8x3EhUs3TIv0HIyfMLnvyfVD/Uaoxb2MjPfNU67taBYUCb77KieSu93Asiut75qdhM5NysdYHnvN28A+Z6SSlzyl5uc4VKLt4V9a7RkBWpGoyu0b/jfwGhJywXmUqyqN8Rk2EqeOmIZeDZDVtS7YJ651MxqYE=
ARC-Authentication-Results:	i=1; server2.sourceware.org
X-Google-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20230601; t=1705904312; x=1706509112;
	h=content-transfer-encoding:to:subject:message-id:date:from:reply-to
	:mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
	:reply-to;
	bh=RFUsTHyj5440NOjioXeWwOvVW433AEf2L17y3eeJ9js=;
	b=qjbPpYrMtW9RBpI+AgIJOjzdAxJ8vLXS1Eib8bT61tXxkK8aVPxxrG4b5oRnp4ldf2
	9l/0Fzx5dyS2fKVmmQA921cEY9CvUTZoe1a7ktCzsdbvKpKjpr2U/9qvuaaK1rIFNt1f
	vq3RCLJKmGAf4DYNUonFh7sBAFJIIqYY8scx3zRVvYSkL9YLu1i9nzOXR1iS5poP4794
	rQHS8Lrs6tGDma/8Z9bfeTl5H9yq+o+G2m3gsWI0uNsxaPtospJLJYixQyzsrQoGLMKC
	ETQgR0VwT7EXW2s1fFi94YbjSuql9qB3nS+nBrlID9BUChLpgV/V2UiAlkmGRV6MkAz0
	rmzQ==
X-Gm-Message-State:	AOJu0Yybf/ZNkcB6GHjcyVZlvhF2/q68qmyqz0cVdsZZZuzGsvnMfJcT
	bETEBuyRwiaz3cFN/wSaw0GSGuTvriWmqJL0e6Aq0G49ZI1aHHoNvZaVXDLugh451XSs2l2XxGq
	c2R+YLDfwbcFk0W9JEddmTj6+1OtD5v/u/gy02g==
X-Google-Smtp-Source:	AGHT+IGKnQeVfxdtr7HRomza6ju2BZGzs5NJtKEu0qWveQyTgq7LqchhZcHXbpQ4s0Py9hNZVD/lR3WQ8/w/GOWCIog=
X-Received:	by 2002:a5b:189:0:b0:dbe:3a98:5977 with SMTP id
	r9-20020a5b0189000000b00dbe3a985977mr3471840ybl.62.1705904312370; Sun, 21 Jan
	2024 22:18:32 -0800 (PST)
MIME-Version:	1.0
Date:	Sun, 21 Jan 2024 22:18:20 -0800
Message-ID:	<CAOBROv1Jgj1cZ6nL64Y=rYRR5cvd8VRw3XH0xD4E57c_=MKU=w@mail.gmail.com>
Subject:	cygwin utils can access directory and its contents, but W10 utils
	claim to have no access, why?
To:	cygwin AT cygwin DOT com
X-Spam-Status:	No, score=1.3 required=5.0 tests=BAYES_00, CLAIM_SUBJECT,
	DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM,
	RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP,
	T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6
X-Spam-Level:	*
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-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:	John Ruckstuhl via Cygwin <cygwin AT cygwin DOT com>
Reply-To:	John DOT Ruckstuhl AT gmail 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 40M6IvF3030707

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

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