From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from forward102o.mail.yandex.net (forward102o.mail.yandex.net [37.140.190.182]) by sourceware.org (Postfix) with ESMTPS id DC0F33857417 for ; Fri, 16 Jul 2021 04:50:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org DC0F33857417 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=yandex.ru Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=yandex.ru Received: from myt5-0656389fa3f6.qloud-c.yandex.net (myt5-0656389fa3f6.qloud-c.yandex.net [IPv6:2a02:6b8:c12:1119:0:640:656:389f]) by forward102o.mail.yandex.net (Yandex) with ESMTP id 824806681A7F; Fri, 16 Jul 2021 07:50:02 +0300 (MSK) Received: from myt5-aad1beefab42.qloud-c.yandex.net (myt5-aad1beefab42.qloud-c.yandex.net [2a02:6b8:c12:128:0:640:aad1:beef]) by myt5-0656389fa3f6.qloud-c.yandex.net (mxback/Yandex) with ESMTP id TFd8ZltLas-o1IeLPG5; Fri, 16 Jul 2021 07:50:02 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1626411002; bh=K44AcknJ6Cp3Y5m6/LPzt1JH32WzHdtJMrXkeNahUDc=; h=In-Reply-To:Subject:To:From:Message-ID:References:Date:Reply-To; b=kcfcE1fFWqadguvMRZxK5kwYGaI7Ci5kUDccwiRt2dCRt4kyo8Ej0wHHfKDg0UAug 4EM27mG8mmbuDALdnhytIHKwlka4H3z8SMY7l9HWf+yvX80BhQPPMBm1dBvZXnA+Jz aLej4pG1vPbX79a1RVLrL3DNDH4Ispf0rcgwH8z8= Authentication-Results: myt5-0656389fa3f6.qloud-c.yandex.net; dkim=pass header.i=@yandex.ru Received: by myt5-aad1beefab42.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id Wu8Iko0s0E-o13mGoVv; Fri, 16 Jul 2021 07:50:01 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) Received: from [192.168.1.10] (HELO daemon2.darkdragon.lan) by daemon2 (Office Mail Server 0.8.12 build 08053101) with SMTP; Fri, 16 Jul 2021 04:44:17 -0000 Date: Fri, 16 Jul 2021 07:44:16 +0300 From: Andrey Repin X-Mailer: The Bat! (v6.8.8) Home Reply-To: cygwin@cygwin.com X-Priority: 3 (Normal) Message-ID: <941829174.20210716074416@yandex.ru> To: L A Walsh , cygwin@cygwin.com Subject: Re: objects created in a dir w/cygwin mangled perms; inherit no-access In-Reply-To: <60EFDD84.8040401@tlinx.org> References: <60E14AAA.4000404@tlinx.org> <514405575.20210704172015@yandex.ru> <60E460C7.7010203@tlinx.org> <685980612.20210707214357@yandex.ru> <60EFDD84.8040401@tlinx.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_THEBAT, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: cygwin@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2021 04:50:07 -0000 Greetings, L A Walsh! > On 2021/07/07 11:43, Andrey Repin wrote: >>>> What is "progd" ? Did you mount some directory into Cygwin tree? >> >>> Sorta, actually the cygtree mounted at 'C:\'. >> >> Ugh. Been there twenty years ago. Had a lot of unexpected issues and finally opted out of it. > --- > If you have something unexpected happening on your own > computer, and you choose not to find the cause, you really don't > know if it was a virus, malware or some other problem. I've found the cause, which does not change the fact the documented behavior was undesirable. This is, after all, whyinstalling Cygwin in a system root is discouraged. > I've had my directory tree mounted the way it is since > Windows XP, and have tried to understand issues about computers > that many term "magick" (or black magick). Being a computer > scientist, I've always tried to understand what was going on. > I don't always find out quickly, but I often return to problems > that I haven't solved years later to sometimes find the cause, or > sometimes find the problems have gone away. > Considering my life has been about computers, opting out > has really not been an option for me. "Doctor, when I poke my eye with a knife, it pains me!" >>> Certainly, having it create no-access dirs >>> for the user isn't desirable. I'm betting that they'd >>> be denied locally as well if my local user didn't >>> have admin override rights. >> >> It may be something in the parent directory. > --- > Nope... can't be, windows doesn't work that way. > A directory can affect its contents, but permissions that are > inherited can't skip a generation. > or fstab mount options. > --- > I pretty much use the default: > ---- > # /etc/fstab > # > # This file is read once by the first process in a Cygwin > # process tree. To pick up changes, restart all Cygwin > # processes. For a description > # see https://cygwin.com/cygwin-ug-net/using.html#mount-table > # This is default anyway: > none / cygdrive binary,posix=0,user 0 0 > ---- This, basically, tells Cygwin to override Windows permissions manager. Creating all sort of permission issues for unsuspecting Windows programs. Saner approach would be to leave Windows permissions to Windows. none / cygdrive noacl,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 But then again, consider you have two conflicting permission schemes over directories on the system drive. >> Needs a more thorough investigation. But I think it would easily be avoided by a saner directory layout. > --- > What is more sane, ignoring a problem that was opted out > of for 20 years, or understand what causes problems. That's baseless assumption. The problem was thoroughly investigated and the final decision was that the lowest number of workarounds is preferable. > I can't speak for Windows 10, but through Windows 7, > especially in the X64 world, it makes little to no sense to > cut your cygwin tools off from being able to access and work > on your windows installation. Eh? I have Cygwin in %PATH% and use its tools primarily, even though I have Git for Windows for example. Which I only use for VS Code. Exception is curl and tidy, both of which I have native builds. > If you have ever boot to a rescue system running from > your hard drive -- you have the choice of using all your cygwin > tools to recover your system, or to just use Windows tools. I have my own rescue system. I'm a support engineer after all. These are tools of my trade. And for the record, TakeCommand is more useful for rescue tool than Cygwin. I have both. > If you have 30+ years of unix/linux/posix experience > with linux/posix tools, does it make any sense to throw that > away when trying to recover your system? When system is not Linux/UNIX? Absolutely. Use right tool for the job. I only have 12 or so years of *NIX experience, and I would never ditch a chance of using bash script to do the work for me, but if I have a choice of native tool that's almost equivalent in performance, I'd use that. > X64 Cygwin tools work natively when installed at root. They work equally well when installed in C:\Programs\Cygwin64. JFYI. > Many of the Windows tools are still x32 which won't run on a rescue system. That's why I opted for 64-bit tools where possible. In my experience, they work faster on 64-bit system, than 32-bit tools, even if built from same source. > Linux xfs has 2 acls on directories -- one for the directory > and one that can be the default for contents to inherit. It's > not identical to windows, but it is similar and if you > understand one, the other isn't that different. Cygwin > has placed the most emphasis on POSIX compatibility vs. > Windows compatibility. In some places it could have been > more Windows compatible and still achieved POSIX compat. I'm familiar with POSIX ACL's. > I do know, that if you have several added Deny > acls added to every file, it can mess up default inheritance > on content files. What windows has added to the mix has to > be deleted -- special perms for creators (user+group). It's > similar to default perms in linux, but it isn't the same. It > is messed up, other devs have said so -- cygwin perms will conflict > with windows perms when they are mixed. They've never tried to > fix that. The result are utilities and permissions that > have 'no access' set for 'creators' (usually owners). That's > not a desired feature unless you opt out of using the windows > GUI. But that's the main reason I use it, so what's the point? > In any event, I know there are bugs in cygwin, but > I don't care enough + know enough about windows development > to fix them. That doesn't mean I opt out of using Cygwin > or Windows (if I can help it), but it doesn't mean I won't > report problems or bugs when I encounter them (doesn't mean > I will either, depends on time). Anyway...opting out of > understanding why things are or work they way they do is not > something I can easily do, by nature. I'm too curious. > (too much so, for the time I have to deal with things!). The reasoning for things to work like that is well explained in the documentation. Though, if you have found a special case that should be avoided, and it looks like so, things may improve with your help. -- With best regards, Andrey Repin Friday, July 16, 2021 7:11:36 Sorry for my terrible english...