From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yb1-xb2c.google.com (mail-yb1-xb2c.google.com [IPv6:2607:f8b0:4864:20::b2c]) by sourceware.org (Postfix) with ESMTPS id 930BE3858429 for ; Mon, 22 Jan 2024 06:18:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 930BE3858429 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 930BE3858429 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::b2c 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 Received: by mail-yb1-xb2c.google.com with SMTP id 3f1490d57ef6-dc2501ed348so1814040276.0 for ; Sun, 21 Jan 2024 22:18:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705904312; x=1706509112; darn=cygwin.com; h=content-transfer-encoding:to:subject:message-id:date:from:reply-to :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=RFUsTHyj5440NOjioXeWwOvVW433AEf2L17y3eeJ9js=; b=Ls4WKs+COudqbZDWhf+PXSEZzoRN3GoR8KLwwc321uIHtLWJPpG+BmcvegPjedu3gy ZeaQs/qeHk/sOFo8Z1LS7NIciGYxdmto5LZ9XaKraQwDQrl8yv2rdk/mpaDrhyqYRHlE W/ASQFSd7VUm1/3uf8lRXzDiv8m0oJ/D+k0Op9ARm6eXrg5Vm6KhyTlmn3j+1gd7FDDx dh8zajnYR1W7Npep5eY0da1Bkesoy7mx1aZHI7wX9IVv0vlmVIQGwO04ZwJeLfmSGAhQ pA8uxR8Awbjc4aZjsEZyfPkJWUqthbniho+jWXa/97r0LjQrlOuXEtOF3w0zSDlLpcrc 3itg== 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 Reply-To: John.Ruckstuhl@gmail.com From: John Ruckstuhl Date: Sun, 21 Jan 2024 22:18:20 -0800 Message-ID: Subject: cygwin utils can access directory and its contents, but W10 utils claim to have no access, why? To: cygwin@cygwin.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 List-Id: 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=3D0 at boot) I have a 3rd-party program =E2=80=9Cyabba=E2=80=9D that many different user= s run (on the same shared PC). It leaves behind a =E2=80=9Ctemporary=E2=80=9D dir (under C:/Users/username/AppData/Local/Temp), each time it=E2=80=99s 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 fol= ders. 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=3D_MEI21002 $ D2=3D_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 examp= le, $ 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