Hi Rainer, On Dec 15 20:29, Dr Rainer Woitok wrote: > Corinna, > > On Monday, 2015-12-14 15:05:32 +0100, you wrote: > > > find: './System Volume Information': Permission denied > > > > This is normal if you don't run your shell elevated. Try again in an > > elevated shell. > > 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! > > 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: > > 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 > > 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. 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) > > > $ > > > > I can't reproduce this one. > > 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 -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
pgpQwizSxFttJ.pgp
Description: PGP signature
