X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=UEOiMKPDxtYIfz94v45BMgqKb6oVJH+cTDCxrRhHok/zTBazMfjKr
	dZDchPt8ifnAAYpfsjnR6Sgunxh8anIrL6xMzVB4Z8kBoKJJPPGBlYyGQO1jqQMf
	5gneYxir09GtqBcixi+AhFvNtQASOSFuU6WKhy6tXXedMpnMvjSGBM=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; s=default;
	bh=58F0eT1nrYrhTIC4F0xvi1Qgw1U=; b=s8A1h0NQbFzCquj1a3UrtsUA5YPS
	6rWQ1FH0m0pe1BV6a3SUhSYaGdJ7mLMHG9a0b0YZdFJ5Ib2weDxrYQ30s2ooO3up
	nS2p2KO/sDMGVyxs70WUwsAYaTGAU+SexP4ok1eCHn/BtGmDnqMSa/Xsxyexok7Z
	LdTyAx0se3Ifvyc=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
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
Date:	Sat, 4 Nov 2017 17:37:01 +0100
From:	Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To:	cygwin AT cygwin DOT com
Subject:	Re: No way to use ssh ~/.ssh/config with "noacl" option
Message-ID:	<20171104163701.GA23538@calimero.vinschen.de>
Reply-To:	cygwin AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
References:	<59FD8C99 DOT 8010703 AT gmail DOT com> <20171104113723 DOT GC18070 AT calimero DOT vinschen DOT de> <59FDA8D9 DOT 6050808 AT gmail DOT com> <59FDC12F DOT 1080005 AT codespunk DOT com> <59FDDCFA DOT 9030306 AT codespunk DOT com>
MIME-Version:	1.0
In-Reply-To:	<59FDDCFA.9030306@codespunk.com>
User-Agent:	Mutt/1.9.1 (2017-09-22)

--SLDf9lqlvOQaIe6s
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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"

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

- Raw text -