From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 92994 invoked by alias); 4 Nov 2017 16:37:07 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 92985 invoked by uid 89); 4 Nov 2017 16:37:07 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-101.0 required=5.0 tests=AWL,BAYES_00,GOOD_FROM_CORINNA_CYGWIN,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_BRBL_LASTEXT,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=hood, Ssh, ownership, 100770 X-HELO: drew.franken.de Received: from mail-n.franken.de (HELO drew.franken.de) (193.175.24.27) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 04 Nov 2017 16:37:05 +0000 Received: from aqua.hirmke.de (aquarius.franken.de [193.175.24.89]) (Authenticated sender: aquarius) by mail-n.franken.de (Postfix) with ESMTPSA id B3110721E281A for ; Sat, 4 Nov 2017 17:37:02 +0100 (CET) Received: from calimero.vinschen.de (calimero.vinschen.de [192.168.129.6]) by aqua.hirmke.de (Postfix) with ESMTP id F1E785E0380 for ; Sat, 4 Nov 2017 17:37:01 +0100 (CET) Received: by calimero.vinschen.de (Postfix, from userid 500) id DC443A8068D; Sat, 4 Nov 2017 17:37:01 +0100 (CET) Date: Sat, 04 Nov 2017 16:37:00 -0000 From: Corinna Vinschen To: cygwin@cygwin.com Subject: Re: No way to use ssh ~/.ssh/config with "noacl" option Message-ID: <20171104163701.GA23538@calimero.vinschen.de> Reply-To: cygwin@cygwin.com Mail-Followup-To: cygwin@cygwin.com References: <59FD8C99.8010703@gmail.com> <20171104113723.GC18070@calimero.vinschen.de> <59FDA8D9.6050808@gmail.com> <59FDC12F.1080005@codespunk.com> <59FDDCFA.9030306@codespunk.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="SLDf9lqlvOQaIe6s" Content-Disposition: inline In-Reply-To: <59FDDCFA.9030306@codespunk.com> User-Agent: Mutt/1.9.1 (2017-09-22) X-SW-Source: 2017-11/txt/msg00084.txt.bz2 --SLDf9lqlvOQaIe6s Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 4885 On Nov 4 11:30, Matt D. wrote: > On 11/4/2017 9:31 AM, Matt D. wrote: > > On 11/4/2017 7:47 AM, Matt D. wrote: > > > On 11/4/2017 7:37 AM, Corinna Vinschen wrote: > > > > On Nov 4 05:47, Matt D. wrote: > > > > > I mount with "noacl" as I don't need ACLs for my purposes and pre= fer to > > > > > leave everything up to Windows permissions. > > > > >=20 > > > > > The problem with this is that ssh insists that ~/.ssh/config be l= ess > > > > > permissive. But this file is bound to --rw-r--r-- for this option. > > > > >=20 > > > > > Would it be appropriate to request ssh to ignore this requirement= when > > > > > "noacl" present on the mounted volume? > > > >=20 > > > > Yes, in theory. However, this shouldn't be necessary. > > > >=20 > > > > Ssh already has code to check extrem perms only in "acl" mounted > > > > directories, but it does not have this extra check for config files, > > > > basically because it was never necessary: > > > >=20 > > > > If you use noacl, your file perms are faked to always be 644, or > > > > 444 if the DOS R/O bit is set, or 755/555 if executable/directory. > > > > Additionally all files are faked as if they are owned by your own > > > > account. > > > >=20 > > > > Ssh checks the config file like this: > > > >=20 > > > > if (((sb.st_uid !=3D 0 && sb.st_uid !=3D getuid()) || > > > > (sb.st_mode & 022) !=3D 0)) > > > > fatal("Bad owner or permissions on %s", filename); > > > >=20 > > > > Which means, 0644 permissions are perfectly fine. As are 755 perms > > > > for the ~/.ssh and ~ dirs. > > > >=20 > > > > I just mounted my home dir "noacl". The perms are as expected: > > > >=20 > > > > $ ls -ld . .ssh .ssh/config .ssh/id_local > > > > drwxr-xr-x 1 corinna vinschen 0 Nov 4 12:27 . > > > > drwxr-xr-x 1 corinna vinschen 0 Mar 14 2017 .ssh > > > > -rw-r--r-- 1 corinna vinschen 703 Jan 19 2017 .ssh/config > > > > -rw-r--r-- 1 corinna vinschen 7329 Jan 12 2017 .ssh/id_local > > > >=20 > > > > Note especially the too open perms in case of the private keyfile > > > > "id_local". Still, I can ssh into one of my other machines just fi= ne. > > > >=20 > > > > How come this doesn't work for you? > > > > [...] >=20 > The code "sb.st_mode & 022" will always be true unless the group and other > bits are set to 0. So 755, 644, 555, or whatever would not work. The test is (sb.st_mode & 022) !=3D 0 and that checks if write perms for group or other are set. If so, your perms are too open. Given that perms are always faked as 644 under "noacl", that test is entirely sufficient. > I made a test build which output the value of sb.st_mode and it displayed= as > "100770". This value reflected the actual NTFS ACLs and not what was > displayed at the bash prompt or by "stat -c %a" (which says 644). There's a disconnection here. Consider: Where's ls getting the values from, if not by calling stat? If your build does not show the same values, then I *bet*, your test application is not using the same path as if you're using the coreutils stat tool. Apparently they access the file via different mount points, one of them "acl", the other "noacl". > This makes sense because Cygwin is pulling the NTFS permissions as there = are > no Cygwin ACLs defined. That's'a misconception. Cygwin ACLs *are* Windows ACLs. There is only one type of ACLs under the hood, and that are the ACLs stored as metadata by the OS. Cygwin, as a userspace DLL, just creates ACLs which resemble POSIX permissions. But that doesn't change the fact that these ACLs are system ACLs. Again: - On "acl" mounts Cygwin uses the underlying Windows ACLs to load and store *real* access information. - On "noacl" mounts Cygwin never actually read ACLs. It just fakes permission bits based on the DOS R/O bit and the file type. And it always fakes ownership so ls -l claims you are the owner of every file on your system, as long as the path goes via the "noacl" mount point. > The only workaround is to use Window's Security diaglog to disable inheri= ted > permissions and remove the Users group. This does seem to satisfy things. >=20 > I suppose the argument now is whether this behavior should change in the > face of a drive mounted with "noacl". It took a bit of guesswork as neith= er > chmod or setfacl was changing the NTFS permissions. The problem is that you only look at this from the ssh perspective, not from the Cygwin DLL perspective. I can *guarantee* you that a "noacl" mount point behaves as described above. The only explanation making sense here is that you think you're accessing a file via a "noacl" mount, but actually you're not. Check your system, and if you're still in doubt, check the Cygwin source. Corinna --=20 Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat --SLDf9lqlvOQaIe6s Content-Type: application/pgp-signature; name="signature.asc" Content-length: 819 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJZ/eytAAoJEPU2Bp2uRE+gC9YP/2zjIDJE5wujyNJvMm7a5GvJ UYqUvNkW44nS4I9ex+Xbryp9PbPcFGJu8mK5uP+QKqvDYPb6mp5ojU1xz9T+F1ZC yKoeZVydVTTBarX8xXNxjygdFijCnhHCQOZmVdqseVl1U2h8iBPmBB0moWXxOr0w QtijAtnMg1Rt+1LHC4hdtSdwse4q5FgeACPccZYkPV133JUQery8v8ojqCNdeL3W dPOVgDDvBZ321K3QgQ4w39ti+2C6ZFawu+uHz3nFahL4zmlGo/7FUcoRvHEo01jx R4ihb3R/sDLrlCRugU8zmFLKNnxMKWePiNkI+20x2wl7qcyc88sS5ri+AiGFHC5i UWlm/3vuPFvnOxzHVKFQCqFJIvr9ATZOzNzV58uwT83QTsO/ygte3sft7GIytE0O nFGttEaHri1oSDzOliKlIn512b/ORjaj1/yPvPm/2C5/lQwissBh/zmFHiBa5R7N OSlMMJc4Og3qYsH639yGTf8T1WkDKgYlZg0TfeSZHRNq7OT0kPGdjeS4lSGiBZUv T3pUQFoChWN2sd6tluNADgM3LvFjzYtzHnGFCBURiDSZsRssfOwoT5etwMehlEWi 6OXyOehNLV5ZzftAFkiRvEolVg6I6rWsfsHlM2NUDQ0tzkUjq8xqZ61TNGSjxKbo 1yYpuFXicWe4ki/Pj5x3 =3Nds -----END PGP SIGNATURE----- --SLDf9lqlvOQaIe6s--