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=oa8tJz0yWJPi9kmeRBfyf+1PyBXXSsIqTgYSAskgs2WwutbYBlOgK
	sQetLaEessmVErMLOIpV3MZOqRTj5ZcIrQgqJ1u9Jx7mUqRdgjnS5hkRNFqMyC1E
	rXTI/SdmA10F+PBhz2jHKfDnMDTibo+euvA1xqOKTyBLZ4RUEBnp8I=
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=B6jkDvm/e9JJZI+O7k/i9hdh6KE=; b=lkPojlDn+wmEQk5wk8z2OBt8lefV
	mV4/e20DxuxfflaA1hxi+uR8r+5kxCdhsfkZMk65OVBDtFrQT+fO1h5bwID+cvdE
	on5ZD3bZEkhczrNcDZelHNJekEBpU0Y4Ug5B/QO+1SfQ8i/uz27RruqVK/TXMqbX
	VhwPhSS4xDnEXlg=
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=-89.9 required=5.0 tests=AWL,BAYES_50,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW,SPAM_BODY1,SPF_HELO_PASS,USER_IN_WHITELIST autolearn=no version=3.3.2 spammy=0.998-1--H*RU:188.192.47.232, 0.998-1--H*RU:sk:ipbcc02, 0.998-1--Hx-spam-relays-external:sk:ipbcc02, 0.998-1--Hx-spam-relays-external:188.192.47.232, 0.998-1--H*RU:Postfix
X-HELO:	mail-n.franken.de
Date:	Wed, 16 Dec 2015 17:47:58 +0100
From:	Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To:	cygwin AT cygwin DOT com
Subject:	Re: SegFault running "ls -l" after Microsoft Patch Day
Message-ID:	<20151216164758.GL3507@calimero.vinschen.de>
Reply-To:	cygwin AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
References:	<20151214140532 DOT GA29983 AT calimero DOT vinschen DOT de> <22128 DOT 27151 DOT 454000 DOT 939910 AT woitok DOT gmail DOT com>
MIME-Version:	1.0
In-Reply-To:	<22128.27151.454000.939910@woitok.gmail.com>
User-Agent:	Mutt/1.5.23 (2014-03-12)

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

Hi Rainer,

On Dec 15 20:29, Dr Rainer Woitok wrote:
> Corinna,
>=20
> On Monday, 2015-12-14 15:05:32 +0100, you wrote:
> > > find: './System Volume Information': Permission denied
> >=20
> > This is normal if you don't run your shell elevated.  Try again in an
> > elevated shell.
>=20
> Hm.  I have several  NTFS formatted USB sticks  and a script which keeps
> them up  to date by  -- among other things --  running a  "find" command
> against their mount points.   Until Tuesday this script never complained
> about a "./System Volume Information" directory,  but since Wednesday it
> does.  If you are saying complaints regarding protected system files are
> normal for an  unprivileged Cygwin user,  one of these patches must have
> freshly created these directories on Wednesday when I plugged in the USB
> sticks.  At least the modification dates of the "./System Volume Inform-
> ation/" directories on these USB sticks do not contradict this theory.

That's ok.  Given the nature of this folder the OS will create it if
it thinks it needs it.

> I'll try to remove these directories  on the USB sticks  as soon as this
> issue is solved somehow.

Ultimately the OS will probably recreate the dir at one point depending
on your system settings.
http://blogs.msdn.com/b/oldnewthing/archive/2003/11/20/55764.aspx

>    Since my "/etc/passwd" file
> uses more Unix like names even for the typical Windows accounts,

Which doesn't make much sense from my POV, but, anyway.  As long as the
entries are correct.

> I then
> ran these commands  with an additional  "-n" option to produce less con-
> fusing listings, ... and low and behold,  now all five commands succeed-
> ed in BOTH, the privileged and the unprivileged shell!
>=20
> I then  inspected my  "/etc/passwd" file and  removed the last line from
> it, which I had added long ago to fight the "Unknown+User" and "Unknown+
> Group" entries in the "ls -l" output:
>=20
>    other:*:4294967295:4294967295:::

Ouch!

> Now all five commands above succeed for the privileged user (though with
> an ouput cluttered with "Unknown+*" entries :-), and at least the normal
> "ls -l /C" command  now also succeeds  for the  unprivileged user, while
> the other four "ls -ld" commands are still segfaulting.  Finally, I also
> removed the corresponding line
>=20
>    other:*:4294967295:

Ouch, ouch!

I'm probably not paranoid enough for this job.  The above are invalid
passwd and group entries.  passwd and group files *main* job is to map
a Windows SID to a Cygwin uid/gid.=20

Apart from the obvious fact that both files are not required anymore,
the above entries will lead to an invalid SID stored for an account
called "other".

The questions you should ask yourself: Why are there SIDs unknown to
Cygwin, despite Cygwin fetching account info directly from Windows?

Apart from the explanation in
https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-how,
there are files in the top level directory of your drive way which
disallow non-admin users to read the file's security information, thus
Cygwin can't fetch the owner and group SIDs, thus the SIDs are
"Unknown".

However, start the shell elevated and you'll see that most of the files
are owned by "SYSTEM" or "TrustedInstaller".  Only pagefile.sys,
swapfile.sys and (I think) hiberfile.sys are locked exclusively by the
OS, so even an admin user can't read the security descriptor.

The bottom line is, by adding the aforementioned entries to /etc/passwd
and /etc/group you not only create invalid passwd and group entries
which only work by happenstance, you also hide the *real* information
from yourself, even if you're running an elevated shell.

To me this sounds like a bad idea.  Personally I rather see what's
really there.

> from my "/etc/group" file  and -- you guessed it -- now everything works
> in both, elevated and normal shell.  Sigh.

Good!

> What is still missing  is some sort  of explanation.   How can a Windows
> patch cause these  two lines in  files "/etc/passwd" and "/etc/group" to
> fail working,  and why is the  effect different,  depending on privilege
> status?   (Remember:  I first applied  Windows patches,  then I ran into
> problems, and finally I updated Cygwin).

Well, *shrug*.

> > ...
> > > $ ls -lF /C
> > > Segmentation fault (core dumped)
> > > $
> >=20
> > I can't reproduce this one.
>=20
> Perhaps you can now with this additional information :-)

Yes.  The OS function RtlCopySid crashes trying to read an invalid SID
structure.  I applied a fix and uploaded a new developer snapshot to
https://cygwin.com/snapshots/ and created a new test release 2.4.0-0.11
for testing.  Please give any of them a try.


Corinna

--=20
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

--GBDnBH7+ZvLx8QD4
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWcZW+AAoJEPU2Bp2uRE+gD1YP/jjmOZjOEhJtgqsSGyoKCtWZ
lRGEEU6yXAWVUPHyXQP4Pon9j4pB0WLeKxES9/LMMlZSjFzKDSIHfA0W6/d/TA40
Kpbcuo0sosWZJG1nNM/8JClR8KpPFGbcSd4kpbgvC4U7FdoubkctvwEo24fUKPjY
95Csa2pwqvNE2cmwkMCj1SX1WNFOmlLMXCXkAH0fDF4fS/LU9QDUkBYB8yfH2XkQ
W51uXtUHQ57n4l6m0BINIBZYhF4isfIAkr1G4M1BJmjKy/L+n7VVE1pBGSht1jUA
2oj1PoQz/tnk8A3OnD3tWLJ3wJs2/brKmeLNItAsrio7x+gt+Ow4JA521AvqBRAS
bm/95xfbGs06i6KqwB4xTmzT4MViHMml79DvxpfsZex+fGHpV8c8MzSMzjHnBLFl
StFyWrU4ykL0st2kbzXjVN0OfapD7Y7V5PSSUVvUgpjvG4fvHueqEP8MVJFwOGBz
FloH+MGiUPyszu4n+zaFb0r9JuYy/GO5Ur52TtM0kB6TSZcsem4n8LCN07KMlToJ
0SJJmtXSKjbJykghlziTT0Plh1eK2PWTn6vGK3WC4eOT7bNiKbS/c/he80kP5oua
2Dq+lCvX1IOfIEMsk5nKBZ9HBnI845m5iiBHDwXemuPqE1KBAUQU0mXa1aavwu09
AbwnubfYOq54Pb6pIyli
=RvT6
-----END PGP SIGNATURE-----

--GBDnBH7+ZvLx8QD4--

- Raw text -