From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.9]) by sourceware.org (Postfix) with ESMTPS id 42D6C386EC62 for ; Wed, 9 Sep 2020 17:08:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 42D6C386EC62 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=SystematicSw.ab.ca Authentication-Results: sourceware.org; spf=none smtp.mailfrom=brian.inglis@systematicsw.ab.ca Received: from [192.168.1.104] ([24.64.172.44]) by shaw.ca with ESMTP id G3ZpkPoRs62brG3ZskzgPI; Wed, 09 Sep 2020 11:08:12 -0600 X-Authority-Analysis: v=2.3 cv=LKf9vKe9 c=1 sm=1 tr=0 a=kiZT5GMN3KAWqtYcXc+/4Q==:117 a=kiZT5GMN3KAWqtYcXc+/4Q==:17 a=IkcTkHD0fZMA:10 a=GBTExFm2I6Mw7kHAeuUA:9 a=4y67wmGMrMU5CHPR:21 a=62qRmbMuKmlzCel_:21 a=QEXdDO2ut3YA:10 a=nxFJi58FgSUA:10 Reply-To: cygwin@cygwin.com Subject: Re: cygwin permissions on folders creating problems for windows applications (like explorer, gvim) To: cygwin@cygwin.com References: <5F587C4E.5090007@tlinx.org> From: Brian Inglis Autocrypt: addr=Brian.Inglis@SystematicSw.ab.ca; prefer-encrypt=mutual; keydata= mDMEXopx8xYJKwYBBAHaRw8BAQdAnCK0qv/xwUCCZQoA9BHRYpstERrspfT0NkUWQVuoePa0 LkJyaWFuIEluZ2xpcyA8QnJpYW4uSW5nbGlzQFN5c3RlbWF0aWNTdy5hYi5jYT6IlgQTFggA PhYhBMM5/lbU970GBS2bZB62lxu92I8YBQJeinHzAhsDBQkJZgGABQsJCAcCBhUKCQgLAgQW AgMBAh4BAheAAAoJEB62lxu92I8Y0ioBAI8xrggNxziAVmr+Xm6nnyjoujMqWcq3oEhlYGAO WacZAQDFtdDx2koSVSoOmfaOyRTbIWSf9/Cjai29060fsmdsDLg4BF6KcfMSCisGAQQBl1UB BQEBB0Awv8kHI2PaEgViDqzbnoe8B9KMHoBZLS92HdC7ZPh8HQMBCAeIfgQYFggAJhYhBMM5 /lbU970GBS2bZB62lxu92I8YBQJeinHzAhsMBQkJZgGAAAoJEB62lxu92I8YZwUBAJw/74rF IyaSsGI7ewCdCy88Lce/kdwX7zGwid+f8NZ3AQC/ezTFFi5obXnyMxZJN464nPXiggtT9gN5 RSyTY8X+AQ== Organization: Systematic Software Message-ID: Date: Wed, 9 Sep 2020 11:08:08 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <5F587C4E.5090007@tlinx.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-CA Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfAcoyfZrzqPGPLf84jWfEeYd+VfyfgiKaPo+SRwByJ7NOuqOrT54XPMjSFjCnXB3I6gQv7PYcFJNMlRSu/IShe2/3V2R5CxtmmH+06qnuN08PAqhys3y /Afg38N6ovbngXbX7qAU6+jAX9KzNOTlpanpKyoL/WdkGpxzeI1Kf+EtB+Zqd5fw+xzkdossxxgN7g== X-Spam-Status: No, score=-8.7 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP, WEIRD_QUOTING autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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: Wed, 09 Sep 2020 17:08:16 -0000 On 2020-09-09 00:55, L A Walsh wrote: > I was trying to edit files in > /etc/ssh: > /etc/ssh> gvim sshd_config > Error: Current working directory has restricted permissions which render it > inaccessible as Win32 working directory. > Can't start native Windows application from here. > setsid: failed to execute gvim: Permission denied > The files were owned by a domain account which is broken right now. > An Aside (I think) > (my workstation became unjoined after a windows update and the trust > between workstation+samba DC was broken. Tried removing + re-adding > only to get: > The join operation was not successful. This could be because an > existing computer account having name 'ANY' was previous > created using a different set of credential. Use a different > computer name, or contact your administrator to remove any > stale conflicting account. The error was Access is denied. > So far, I've been stymied on that front as well > End of aside > The dir was owned by a domain account, so chowned it to a local account+ > group, and no effect. Noticed an ACL on it from the + in ls. > my lsacl script shows: > /etc/ssh> lsacl . > [u::rwx,u:Administrators_u:rwx,g::rwx,g:SYSTEM:rwx,g:Users:r-x,g:Authenticated Users:rwx,m::rwx,o::---/u::rwx,u:Administrators_u:rwx,g::rwx,g:SYSTEM:rwx,g:Users:r-x,g:Authenticated Users:rwx,m::rwx,o::r-x] . > and getfacl shows: > /etc/ssh> getfacl . > # file: . > # owner: Administrators_u > # group: Administrators > user::rwx > user:Administrators_u:rwx > group::rwx > group:SYSTEM:rwx > group:Users:r-x > group:Authenticated Users:rwx > mask::rwx > other::--- > default:user::rwx > default:user:Administrators_u:rwx > default:group::rwx > default:group:SYSTEM:rwx > default:group:Users:r-x > default:group:Authenticated Users:rwx > default:mask::rwx > default:other::r-x > Looking in explorer I see > a NULL SID with Deny of Traverse, Read ext attrs and perm, and del subfolders > for the folder only. > Authenticated users get denied for folder Create files/write data, > Create folders /append data, write attrs, write ext.attrs, + delete subfolders+files > Then they get some perms for folder+subfolds+files > and a copy of the null sid denials... > Explorer maintains that "The permissions on etc/ssh are incorrectly ordered > which may cause some entries to be ineffective. In order to change > any permissions, windows requires they be reordered. > I've run into this stuff before with cygwin permissions being incompatible > with windows permissions. I've sort of ignored it for the most part as my > domain account generally had permissions to what I needed, but my local > account hasn't had the same treatment. > So I can reinstall new acls for the local equivalents of the domain > accounts or I can try to figure out why cygwin has to use acls that > are incompatible with windows applications -- and by incompatible, I > mean they won't start. > Oddly enough Samba seems to be able to store cygwin Acls, > in a way that doesn't seem to require a disabling of windows acls > nor linux acls. I may be wrong, but I seem to have a feeling that > this has to do with a decision to use Sun-ACL's in cygwin while > Samba uses Posix ACLs. Also, something I didn't understand is I > seem to remember that something special had to be done to implement > a primary group on the files -- yet, since Vista, MS has had a primary > group on their files to support their POSIX subsystem. Is that > currently being used? If not, would it be possible? > The group ID may not be figuring into how the cyg-acl's are very > incompat with window's acl's, I dunno. > But my main concern is not being able to start any windows apps in > directories where cygwin has set the permissions as they seem to > be incompatible. Can these be made compatible? If there is some > behavior that would have to change in regards to how cygwin acls + > permissions behave, could it be based off an environment variable -- > to use more compatible posix ACL's rather than sun ACL's? > I may be showing a great deal of ignorance, but it seems that cygwin > is supposed to be a posix implementation -- wouldn't posix acls make > more sense? Cygwin used to support Sun ACLs but Corinna's patches changed those to POSIX ACLs implemented using Windows ACLs, so Cygwin ACLs *ARE* legal Windows ACLs, but those where Cygwin ACLs have to start with a NULL DENY ALL ACE do not conform to Windows File Explorer's narrow minded view of what you should be allowed to do with ACEs in ACLs, although nothing else within Windows complains, including chkdsk, dism, scandisk, sfc scannow disk integrity tools, but many Windows backup/restore utilities garble them! If you have files with permissions equivalent to a+r,u+w,go-w ACL u::rw-,g::r--,o::r-- or directories ACL u::rwx,g::r-x,o::r-x,d:u::rwx,d:g::r-x,d:o::r-x or executables ACL u::rwx,g::r-x,o::r-x with permissions equivalent to a+rx,u+w,go-w, just running setfacl -b against *Cygwin* directories or files with those long ACLs will normally reduce those to the minimum required e.g. [sanitized - use icalcs to see real ACEs - *DO NOT MODIFY* non-Cygwin Windows directories and files used by Windows programs] $ lsp .bash_logout .bash_profile .ssh -rwxr-xr-x 1 $USER None 293 Oct 9 2017 .bash_logout # file: .bash_logout # owner: $USER # group: None user::rwx group::r-x other::r-x .bash_logout $HOSTNAME\$USER:(F) $HOSTNAME\None:(RX) Everyone:(RX) Successfully processed 1 files; Failed processing 0 files -rw-r--r-- 1 $USER None 6323 Dec 1 2019 .bash_profile # file: .bash_profile # owner: $USER # group: None user::rw- group::r-- other::r-- .bash_profile $HOSTNAME\$USER:(R,W,D,WDAC,WO) $HOSTNAME\None:(R) Everyone:(R) Successfully processed 1 files; Failed processing 0 files drwx------+ 1 $USER None 0 Mar 8 2020 .ssh # file: .ssh # owner: $USER # group: None user::rwx group::--- other::--- default:user::rwx default:group::--- default:other::--- .ssh $HOSTNAME\$USER:(OI)(CI)(F) CREATOR OWNER:(OI)(CI)(IO)(F) Successfully processed 1 files; Failed processing 0 files [Among Windows File Explorer other lackings is also that it doesn't display file time stamps before 1979-12-31 23:59:59+0000 - they show as blank - reported to MS.] -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in IEC units and prefixes, physical quantities in SI.] lsp - list permissions - is just a hacky bash function that lets me check *ALL* Cygwin permissions without thinking: lsp () { local p o='-n' for p in "$@" do echo $o ls -adlL "$p" && \ echo && \ getfacl "$p" && \ icacls "$(cygpath -m ""$p"")" o='' done }