Re: upgrades hang forever on 0p_000_autorebase.dash
Patrick Mackinlay spacesurfer.com> writes: > It requires user input because the file > /var/cache/rebase/rebase_dyn > is created read only the first time and then the second time a rm > requires user confirmation. When run from setup then rm should not prompt (and it doesn't for my installations), at least not if the permissions on the directory are correct and you always run it under the same UID. I could add a "-f", but... You seem to have some borked ACL on your Cygwin installation (i.e. a fresh installation shouldn't have these) or something's wrong with the UID settings (maybe mopve /etc/passwd and /etc/group files). Do you run setup.exe as administrator? Is this a system-wide or user installation? Also the latest snapshot changes the handling of the Administrator and SYSTEM accounts to resolve some issues with intended vs. effective group rights and ACL mask computation. Regard, Achim. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] httpd 2.4.18-1
The following packages have been uploaded to the Cygwin distribution: * httpd-2.4.18-1 * httpd-devel-2.4.18-1 * httpd-manual-2.4.18-1 * httpd-tools-2.4.18-1 * httpd-mod_http2-2.4.18-1 * httpd-mod_ldap-2.4.18-1 * httpd-mod_lua-2.4.18-1 * httpd-mod_proxy_html-2.4.18-1 * httpd-mod_ssl-2.4.18-1 The Apache HTTP Server Project is a collaborative software development effort aimed at creating a robust, commercial-grade, featureful, and freely-available source code implementation of an HTTP (Web) server. This is an update to the latest upstream release: https://www.apache.org/dist/httpd/CHANGES_2.4 The HTTP/2 (RFC 7540) protocol module has been enabled in a separate package, which depends on libnghttp2. -- Yaakov -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Weird behavior of crypt
Hello.
I'm trying to do SHA-512 password encryption, but the result is really
weird on Cygwin:
# On Cygwin(either 32 or 64) 2.4.1-1, latest updates with crypt 1.1-1,
libcrypt0 1.1-1, libcrypt-devel 1.1-1
$ crypt '$6$7dl4B0fKUimdnR$' test_value
$6wOs/zKP2jDM
$ python -c 'import crypt; print crypt.crypt("test_value",
"$6$7dl4B0fKUimdnR$")' # Python 2.7.10
$6wOs/zKP2jDM
$ perl -e 'print crypt("test_value", "\$6\$7dl4B0fKUimdnR\$")."\n"' #
Perl v5.22.1
$6wOs/zKP2jDM
Am I missing something?
On other system, I get a more expected result:
# On Ubuntu 15.04
$ mkpasswd --method=SHA-512 test_value 7dl4B0fKUimdnR
$6$7dl4B0fKUimdnR$f6gCu.3IfrxhsnJKFnusDH.UudC.lLOSB1G3D1bIboWxlixzBy2xO/3rCKHmzfwekCTvmQd11bPdcsJOaLkCJ.
$ python -c 'import crypt; print crypt.crypt("test_value",
"$6$7dl4B0fKUimdnR$")' # Python 2.7.10
$6$7dl4B0fKUimdnR$f6gCu.3IfrxhsnJKFnusDH.UudC.lLOSB1G3D1bIboWxlixzBy2xO/3rCKHmzfwekCTvmQd11bPdcsJOaLkCJ.
$ perl -e 'print crypt("test_value", "\$6\$7dl4B0fKUimdnR\$")."\n"' #
Perl v5.20.2
$6$7dl4B0fKUimdnR$f6gCu.3IfrxhsnJKFnusDH.UudC.lLOSB1G3D1bIboWxlixzBy2xO/3rCKHmzfwekCTvmQd11bPdcsJOaLkCJ.
# On RHEL 6.6
$ python -c 'import crypt; print crypt.crypt("test_value",
"$6$7dl4B0fKUimdnR$")' # Python 2.6.6
$6$7dl4B0fKUimdnR$f6gCu.3IfrxhsnJKFnusDH.UudC.lLOSB1G3D1bIboWxlixzBy2xO/3rCKHmzfwekCTvmQd11bPdcsJOaLkCJ.
$ perl -e 'print crypt("test_value", "\$6\$7dl4B0fKUimdnR\$")."\n"' #
Perl v5.10.1
$6$7dl4B0fKUimdnR$f6gCu.3IfrxhsnJKFnusDH.UudC.lLOSB1G3D1bIboWxlixzBy2xO/3rCKHmzfwekCTvmQd11bPdcsJOaLkCJ.
--
Alex
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Weird behavior of crypt
On 29/01/2016 12:18, Alexandre Garnier wrote:
Hello.
I'm trying to do SHA-512 password encryption, but the result is really
weird on Cygwin:
# On Cygwin(either 32 or 64) 2.4.1-1, latest updates with crypt 1.1-1,
libcrypt0 1.1-1, libcrypt-devel 1.1-1
$ crypt '$6$7dl4B0fKUimdnR$' test_value
$6wOs/zKP2jDM
$ python -c 'import crypt; print crypt.crypt("test_value",
"$6$7dl4B0fKUimdnR$")' # Python 2.7.10
$6wOs/zKP2jDM
$ perl -e 'print crypt("test_value", "\$6\$7dl4B0fKUimdnR\$")."\n"' #
Perl v5.22.1
$6wOs/zKP2jDM
Am I missing something?
On other system, I get a more expected result:
# On Ubuntu 15.04
$ mkpasswd --method=SHA-512 test_value 7dl4B0fKUimdnR
$6$7dl4B0fKUimdnR$f6gCu.3IfrxhsnJKFnusDH.UudC.lLOSB1G3D1bIboWxlixzBy2xO/3rCKHmzfwekCTvmQd11bPdcsJOaLkCJ.
Not SHA-512, see
/usr/share/doc/crypt/crypt.README
This is the DES-crypt package Version 1.1
It provides a static library libcrypt.a as well as a shared library
cygcrypt-0.dll together with a link lib libcrypt.dll.a, which export
the functions
crypt(3)
encrypt(3)
setkey(3)
The passwords created by crypt(3) are 56 bit DES encrypted and are
100% identical to those created by the Linux crypt().
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: sshd refuses connections since upgrade to 2.4.0-1
On Jan 28 19:56, prs_cyg...@quantentunnel.de wrote: > Hi! > > Long time Cygwin user but first time error reporter to this mailing list. > Since upgrading my 32-bit Cygwin installation on Win7SP1 x64 from > 2.3.1-1 to the current 2.4.0-1 (and also 2.5.0-0.1 in my despair) I > can't connect to sshd running as a service anymore. > The service starts and spawns a child in order to handle the > connection request, but that fails even when connecting from > localhost. > I triaged the problem by trying snapshots between the two releases and > traced it to a change after 20151129: > cygwin1-20151129.dll works > cygwin1-20151203.dll fails > > The sshd.log remains empty. > In order to create more information to go on I ran strace on the > parent (cyg_server spawned) sshd and tried to connect, the strace-log > (sshd_cygwin2.4.0_20160109) is attached together with a slightly > redacted cygcheck.out > > Thanks for looking into this! > > P.S. As can be seen from the strace I'm running Agnitum Outpost > Firewall Pro and the current EMET - both has never been a problem with > Cygwin's sshd (in this installation since May 2010). An "Access denied" error occurs, apparently in a Windows DLL while loading Windows DLLs. It's hard to tell what the reason is, but what strikes me as weird is that the crash occurs right after this Agnitum thingy has been injected into the process: --- Process 17828 loaded C:\PROGRA~1\Agnitum\OUTPOS~1\wl_hook.dll at 1000 --- Process 17828 unloaded DLL at 1000 --- Process 17828 loaded C:\PROGRA~1\Agnitum\OUTPOS~1\wl_hook.dll at 0128 --- Process 17828 loaded C:\Windows\SysWOW64\shell32.dll at 762F --- Process 17828 loaded C:\Windows\SysWOW64\shlwapi.dll at 75DE --- Process 17828 thread 18284 exited with status 0xc022 --- Process 17828 thread 18412 exited with status 0xc022 --- Process 17828 thread 17624 exited with status 0xc022 --- Process 17828 exited with status 0xc022 154769 11583429 [waitproc] sshd 8404 pinfo::status_exit: *** STATUS_0xC022 Did you try excluding sshd from the checks of that scanner? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat signature.asc Description: PGP signature
Re: Weird behavior of crypt
Hi, On Fri, Jan 29, 2016 at 1:39 PM, Marco Atzeri wrote: > The passwords created by crypt(3) are 56 bit DES encrypted and are > 100% identical to those created by the Linux crypt(). crypt(3) on Linux support SHA-256 & SHA-512, $6$ prefix means SHA-512 is requested. Regards, ismail -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: CVS problems on 64-bit cygwin
On Jan 29, 2016, at 12:43 AM, Marco Atzeri wrote: > > On 29/01/2016 05:11, lloyd.w...@yahoo.co.uk wrote: >> >> Under 64-bit cygwin, this doesn't work; I never get a password prompt. > > try with > CVS_RSH="ssh"; export CVS_RSH Good call. I set CVS_RSH in my .bash_profile so long ago I forgot about it. This probably explains why the OP sees the problem change when moving from Cygwin 32 to Cygwin 64: he probably doesn’t use the same shell startup scripts in both cases. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Weird behavior of crypt
On Jan 29 12:39, Marco Atzeri wrote:
>
>
> On 29/01/2016 12:18, Alexandre Garnier wrote:
> >Hello.
> >I'm trying to do SHA-512 password encryption, but the result is really
> >weird on Cygwin:
> >
> ># On Cygwin(either 32 or 64) 2.4.1-1, latest updates with crypt 1.1-1,
> >libcrypt0 1.1-1, libcrypt-devel 1.1-1
> >$ crypt '$6$7dl4B0fKUimdnR$' test_value
> >$6wOs/zKP2jDM
> >
> >$ python -c 'import crypt; print crypt.crypt("test_value",
> >"$6$7dl4B0fKUimdnR$")' # Python 2.7.10
> >$6wOs/zKP2jDM
> >
> >$ perl -e 'print crypt("test_value", "\$6\$7dl4B0fKUimdnR\$")."\n"' #
> >Perl v5.22.1
> >$6wOs/zKP2jDM
> >
> >Am I missing something?
> >
> >On other system, I get a more expected result:
> >
> ># On Ubuntu 15.04
> >$ mkpasswd --method=SHA-512 test_value 7dl4B0fKUimdnR
> >$6$7dl4B0fKUimdnR$f6gCu.3IfrxhsnJKFnusDH.UudC.lLOSB1G3D1bIboWxlixzBy2xO/3rCKHmzfwekCTvmQd11bPdcsJOaLkCJ.
> >
You're aware that the password field in /etc/passwd is not used, right?
Passwords are checked against the Windows user DB. In fact, /etc/passwd
is not necessary anymore.
> Not SHA-512, see
> /usr/share/doc/crypt/crypt.README
>
> This is the DES-crypt package Version 1.1
>
> It provides a static library libcrypt.a as well as a shared library
> cygcrypt-0.dll together with a link lib libcrypt.dll.a, which export
> the functions
>
> crypt(3)
> encrypt(3)
> setkey(3)
>
> The passwords created by crypt(3) are 56 bit DES encrypted and are
> 100% identical to those created by the Linux crypt().
Right. If you need the hashes for other purposes than /etc/passwd,
you can use `openssl sha512'
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
signature.asc
Description: PGP signature
Re: Weird behavior of crypt
2016-01-29 13:09 GMT+01:00 Corinna Vinschen :
> On Jan 29 12:39, Marco Atzeri wrote:
>>
>>
>> On 29/01/2016 12:18, Alexandre Garnier wrote:
>> >Hello.
>> >I'm trying to do SHA-512 password encryption, but the result is really
>> >weird on Cygwin:
>> >
>> ># On Cygwin(either 32 or 64) 2.4.1-1, latest updates with crypt 1.1-1,
>> >libcrypt0 1.1-1, libcrypt-devel 1.1-1
>> >$ crypt '$6$7dl4B0fKUimdnR$' test_value
>> >$6wOs/zKP2jDM
>> >
>> >$ python -c 'import crypt; print crypt.crypt("test_value",
>> >"$6$7dl4B0fKUimdnR$")' # Python 2.7.10
>> >$6wOs/zKP2jDM
>> >
>> >$ perl -e 'print crypt("test_value", "\$6\$7dl4B0fKUimdnR\$")."\n"' #
>> >Perl v5.22.1
>> >$6wOs/zKP2jDM
>> >
>> >Am I missing something?
>> >
>> >On other system, I get a more expected result:
>> >
>> ># On Ubuntu 15.04
>> >$ mkpasswd --method=SHA-512 test_value 7dl4B0fKUimdnR
>> >$6$7dl4B0fKUimdnR$f6gCu.3IfrxhsnJKFnusDH.UudC.lLOSB1G3D1bIboWxlixzBy2xO/3rCKHmzfwekCTvmQd11bPdcsJOaLkCJ.
>> >
>
> You're aware that the password field in /etc/passwd is not used, right?
> Passwords are checked against the Windows user DB. In fact, /etc/passwd
> is not necessary anymore.
>
>> Not SHA-512, see
>> /usr/share/doc/crypt/crypt.README
>>
>> This is the DES-crypt package Version 1.1
>>
>> It provides a static library libcrypt.a as well as a shared library
>> cygcrypt-0.dll together with a link lib libcrypt.dll.a, which export
>> the functions
>>
>> crypt(3)
>> encrypt(3)
>> setkey(3)
>>
>> The passwords created by crypt(3) are 56 bit DES encrypted and are
>> 100% identical to those created by the Linux crypt().
>
> Right. If you need the hashes for other purposes than /etc/passwd,
> you can use `openssl sha512'
My use case is to generate encrypted password for use later on unix
system (using Python crypt library).
OK for crypt(1) providing only 56 bit DES.
But, could be nice for libcrypt (cygcrypt or crypt(3)) to provide
other algorithms so other libraries working with it (like Python or
Perl crypt libraries) could use those. Or at least raise an error when
not supported prefixes are used (like '$6$').
--
Alex
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Updated: emacs-24.5-3 (TEST)
On Sun, Jan 24, 2016 at 1:30 AM, Ken Brown wrote: > The following packages have been updated in the Cygwin distribution as > test releases: > > * emacs-24.5-3 > * emacs-X11-24.5-3 > * emacs-w32-24.5-3 > * emacs-el-24.5-3 > [...] > This is a rebuild of the 24.5-2 packages, patched to allow native Windows > paths like C:\foo or C:/foo in situations where file names are expected. > > If you are interested in this feature, please try the test release and let > me know whether it works the way you expect. Thank you for the packages. I have started to use "emacs-w32-24.5-3", I like the new features and I have not encountered obvious bugs. A shortcoming of the new version "GNU Emacs 24.5.1 (i686-pc-cygwin) of 2016-01-23 on moufang" compared to a mingw version "GNU Emacs 24.3.1 (i386-mingw-nt6.2.9200) of 2013-03-17 on MARVIN", which I also use, is that file-name completion does not work for find-file if a windows-style directory path is used. - Daniel -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Updated: emacs-24.5-3 (TEST)
On 1/29/2016 9:00 AM, Daniel Daboul wrote: On Sun, Jan 24, 2016 at 1:30 AM, Ken Brown wrote: The following packages have been updated in the Cygwin distribution as test releases: * emacs-24.5-3 * emacs-X11-24.5-3 * emacs-w32-24.5-3 * emacs-el-24.5-3 [...] This is a rebuild of the 24.5-2 packages, patched to allow native Windows paths like C:\foo or C:/foo in situations where file names are expected. If you are interested in this feature, please try the test release and let me know whether it works the way you expect. Thank you for the packages. I have started to use "emacs-w32-24.5-3", I like the new features and I have not encountered obvious bugs. A shortcoming of the new version "GNU Emacs 24.5.1 (i686-pc-cygwin) of 2016-01-23 on moufang" compared to a mingw version "GNU Emacs 24.3.1 (i386-mingw-nt6.2.9200) of 2013-03-17 on MARVIN", which I also use, is that file-name completion does not work for find-file if a windows-style directory path is used. - Daniel Thanks for the feedback. I'll see if I can figure out how to make that work. Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: OpenSSH access to join the "Local Account" group
On Thu, Jan 28, 2016 at 10:44 PM, Glenn G wrote: > Very strange. You could log in as the user, regenerate the keys and try > porting it over again. User id shouldn't have anything to do with this > though. Sounds like impersonation is messed up for sshd user on machine b. > > > Sent from my iPad > >> On Jan 28, 2016, at 2:11 PM, Tom Moore wrote: >> >> Hi, >> >> I have a couple of Windows 7 machines set up as OpenSSH servers. Both are >> current with windows updates. Both machines have identical cygwin >> versions (2.0.4-1). I have tried to make the sshd configuration identical >> on these two machines, following the instructions on >> http://www.howtogeek.com/howto/41560/how-to-get-ssh-command-line-access-to-windows7-using-cygwin >> >> >> I have set up the client machines, generated rsa keys, and copied the >> public keys into the authorized_keys file on the server. Now I can log in >> to both machines without providing a password. So far so good. >> >> When I ssh log in to machine A and check the id that I am logged in with, I >> get: >> >> uid=197608(User) gid=197121(None) groups=197121(None),114(Local account and >> member of Administrators >> group),544(Administrators),545(Users),4(INTERACTIVE),66049(CONSOLE >> LOGON),11(Authenticated Users),15(This Organization),113(Local >> account),4095(CurrentSession),262154(NTLM Authentication),405504(High >> Mandatory Level) >> >> which is what I need in order to interact with some other resources on the >> system. >> >> When I ssh log in to machine B and check the id I get: >> >> uid=197608(Owner) gid=197121(None) groups=197121(None),11(Authenticated >> Users),66048(LOCAL),66049(CONSOLE LOGON),4(INTERACTIVE),15(This >> Organization),545(Users),4095(CurrentSession),544(Administrators),405504(High >> Mandatory Level) >> >> However, if on my local client if I remove the private key from the .ssh >> directory and ssh login again, this time having to specify a password, my >> session will join the "Local account" group as I want. >> >> Is there a configuration that I am missing in order to get machine B to >> join the "Local account" group when I log in using an rsa key? What could >> be different between the two machines? >> >> Cheers, >> >> Tom To be clear, the sole administrator account on machine A that I am logging in with has a user name of 'User', and the sole administrative account on machine B that I am logging in with has a user name of 'Owner'. I have correctly set up the rsa keys for me@client on both of these hosts. The different account names are the way that these machines (purchased at different times) were set up by the vendor. I don't know if there any other subtle differences. Also, on machine A I must mount additional disk drives every time I remotely log in by adding "net use" statements in to the .bash_profile. However, on machine B on the second and subsequent remote log in after a reboot the disk will already be mounted and I will get an error message "The local device name is already in use". What do you mean by sshd impersonation? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Updated: emacs-24.5-3 (TEST)
On 1/29/2016 9:16 AM, Ken Brown wrote: On 1/29/2016 9:00 AM, Daniel Daboul wrote: On Sun, Jan 24, 2016 at 1:30 AM, Ken Brown wrote: The following packages have been updated in the Cygwin distribution as test releases: * emacs-24.5-3 * emacs-X11-24.5-3 * emacs-w32-24.5-3 * emacs-el-24.5-3 [...] This is a rebuild of the 24.5-2 packages, patched to allow native Windows paths like C:\foo or C:/foo in situations where file names are expected. If you are interested in this feature, please try the test release and let me know whether it works the way you expect. Thank you for the packages. I have started to use "emacs-w32-24.5-3", I like the new features and I have not encountered obvious bugs. A shortcoming of the new version "GNU Emacs 24.5.1 (i686-pc-cygwin) of 2016-01-23 on moufang" compared to a mingw version "GNU Emacs 24.3.1 (i386-mingw-nt6.2.9200) of 2013-03-17 on MARVIN", which I also use, is that file-name completion does not work for find-file if a windows-style directory path is used. - Daniel Thanks for the feedback. I'll see if I can figure out how to make that work. Actually, completion seems to work for me if I use forward slashes but not if I use backslashes. Can you confirm that? If not, please show me a case where it fails. Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Re: sshd refuses connections since upgrade to 2.4.0-1
>> Hi! >> >> Long time Cygwin user but first time error reporter to this mailing list. >> Since upgrading my 32-bit Cygwin installation on Win7SP1 x64 from >> 2.3.1-1 to the current 2.4.0-1 (and also 2.5.0-0.1 in my despair) I >> can't connect to sshd running as a service anymore. >> The service starts and spawns a child in order to handle the >> connection request, but that fails even when connecting from >> localhost. >> I triaged the problem by trying snapshots between the two releases and >> traced it to a change after 20151129: >> cygwin1-20151129.dll works >> cygwin1-20151203.dll fails >> >> The sshd.log remains empty. >> In order to create more information to go on I ran strace on the >> parent (cyg_server spawned) sshd and tried to connect, the strace-log >> (sshd_cygwin2.4.0_20160109) is attached together with a slightly >> redacted cygcheck.out >> >> Thanks for looking into this! >> >> P.S. As can be seen from the strace I'm running Agnitum Outpost >> Firewall Pro and the current EMET - both has never been a problem with >> Cygwin's sshd (in this installation since May 2010). > >An "Access denied" error occurs, apparently in a Windows DLL while >loading Windows DLLs. It's hard to tell what the reason is, but what >strikes me as weird is that the crash occurs right after this Agnitum >thingy has been injected into the process: > >--- Process 17828 loaded C:\PROGRA~1\Agnitum\OUTPOS~1\wl_hook.dll at 1000 >--- Process 17828 unloaded DLL at 1000 >--- Process 17828 loaded C:\PROGRA~1\Agnitum\OUTPOS~1\wl_hook.dll at 0128 >--- Process 17828 loaded C:\Windows\SysWOW64\shell32.dll at 762F >--- Process 17828 loaded C:\Windows\SysWOW64\shlwapi.dll at 75DE >--- Process 17828 thread 18284 exited with status 0xc022 >--- Process 17828 thread 18412 exited with status 0xc022 >--- Process 17828 thread 17624 exited with status 0xc022 >--- Process 17828 exited with status 0xc022 >154769 11583429 [waitproc] sshd 8404 pinfo::status_exit: *** STATUS_0xC022 > >Did you try excluding sshd from the checks of that scanner? > > >Corinna > After some debugging and playing with different settings in Microsoft's Enhanced Mitigation Experience Toolkit ( https://technet.microsoft.com/de-de/security/jj653751 ) I managed to determine the following as a "cause" for my sshd problems. My firewall (Agnitum Outpost Firewall Pro) does not play any role. With the current release version 5.2 of EMET on Win7SP1 x64 before cygwin1-20151203.dll: All mitigations except ASR (Attack Surface Reduction) could be used (ASR is not needed). Since cygwin1-20151203.dll: The following mitigations must be disabled for sshd to allow connections: * EAF+ (Export Address Table Access Filtering Plus) * Stack Pivot But getting a shell still fails (connection closes before shell starts ?!). For fully working sshd additionally the following mitigation must also be disabled: * Sim Exec Flow (ROP Mitigation) The question is what changes/new codepaths in cygwin1.dll trigger the three mitigations mentioned above since 20151203 ? I would assume especially users in enterprise environments might suffer this "problem"... P.S. I'm sorry for breaking threading, but apparently my freemail provider (gmx.net) does not allow sending email to addresses longer than 60 characters. The subscription confirmation addresses for the list (ezmlm) are at least in my case longer than that (here 88 chars) :( -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] TEST RELEASE: Cygwin 2.5.0-0.2
Hi Cygwin friends and users, I released a new Cygwin TEST version 2.5.0-0.2. This new test release introduces a change which also affects users in terms of the POSIX file permission handling. One of them is a bugfix: - Under some circumstances you could observe a spurious entry for the owning group with no permissions at all, e.g.: $ getfacl foo # owner: hein # group: bloed user::rwx group::r-- group:SYSTEM:rwx group:bloed:--- <--- spurious, this should be gone now mask::rwx other::r-x - Usually POSIX.1e requires that chmod does not change the group permissions but the MASK permissions if additional user and group entries are present. This may result in a confusing behaviour: $ getfacl -c foo user::rwx group::r-- group:blah:r-- mask::r-- other::r-- So the primary group only has read perms. Now let's see what happens when calling `chmod g+w': $ ls -l foo -rwxr--r--+ [...] foo $ chmod g+w foo $ ls -l foo -rwxrw-r--+ [...] foo Looks good so far, but... $ getfacl -c foo user::rwx group::r--<-- Still only read perms, no write perms group:blah:r-- mask::rw- <-- Only the mask has changed other::r-- So chmod g+w does NOT result in the primary group getting write permissions if it doesn't already have them. This is one of the more puzzling aspects of POSIX.1e. The chmod change in 2.5.0 now handles default Windows ACL with entries only for the owner, the group, other, SYSTEM and the Administrators group as if it's a standard POSIX ACL. That is, chmod will not only influence the POSIX MASK entry, but also the owning group entry. The result should be more along the lines of Windows user expectations when calling chmod. Note that this is restricted to *only* the ACLs described above. Any other group present in the ACL will switch chmod back to the POSIX.1e behaviour. Other than that, this release still introduces a major change addressing developers only. tl;dr: Cygwin 2.5.0 switches Cygwin from the Solaris ACL API to the POSIX.1e ACL API. Since the year 2000, Cygwin supports a POSIXoid ACL emulation. This emulation is based on the Solaris API, which is only marginally comparable to the POSIX ACL API defined in the withdrawn draft POSIX.1e(*). At about the same time SGI started to implement POSIX.1e which eventually became libacl in 2001. Libacl is the POSIX ACL implementation used on Linux. With Cygwin 2.4.0, Cygwin introduced a major revamp of the POSIX ACL emulation. This new emulation is complete in the sense that the ACL handling covers all of POSIX.1e quirks. This in turn allows to use the POSIX.1e API. The Solaris API is the base implementation and stays available. The POSIX.1e API is implemented in terms of the Solaris types and mainly a slim layer on top of the Solaris API. Changes for developers: - The full set of POSIX.1e functions is now available. - Most of the libacl extensions are available as well. The only exceptions right now are the two functions perm_copy_file and perm_copy_fd. These can be added later. Somebody just has to do it :) - The header now *only* exposes the POSIX.1e API. - To get access to the Solaris API, you will have to include now. - There's a new header which exposes the libacl extension functions. Please give this new POSIX.1e ACL implementation a test. If you have a project or maintain a package utilizing ACLs, please make sure that your project picks up the new POSIX.1e API and that it works as desired. Have fun, Corinna (*) http://wt.tuxomania.net/publications/posix.1e/ -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
sshd: testing whether login was via public key or password?
Hi, Short version: "schtasks /change" fails because I used SSH public key auth. I'd like to add error checking to script I run, so that it exits if the user doesn't have the right session token (password), and "fix" SSH public key login so I get the right privileges. How best to do that? I've read the following but not sure I understand it enough to pick the "best" method: https://cygwin.com/cygwin-ug-net/ntsec.html The full issue: I'm attempting to remotely change passwords for some Windows scheduled tasks. After logging in (via SSH public key) I could change the passwords for tasks for different (non-admin) accounts, but not my own admin account. # After logging in with SSH pub key: $ id -G | grep -qE '\<(544|0)\>' && echo admin || echo user admin $ whoami Administrator $ schtasks /query /TN "\backup_web_users" /v /fo list | grep 'Run As' Run As User: Administrator $ schtasks /change /RP newpassword /TN "\backup_web_users" ERROR: Logon failure: unknown user name or bad password. ### Note: if one tries to do above cmd repeatedly, you might lock ### your account after too many login attempts # But for a regular user account, it worked OK: $ schtasks /query /TN "\Cleanup Old" /v /fo list | grep 'Run As' Run As User: HOSTNAME\nonadminuser $ schtasks /change /RP newpassword /TN "\Cleanup Old" SUCCESS: The parameters of scheduled task "\Cleanup Old" have been changed. I figured out the above "Logon failure" was due to logging in via SSH public key, reference: https://cygwin.com/ml/cygwin/2004-09/msg00087.html As noted in the reference above, if I login via SSH using my password, I can successfully change the scheduled task password for Administrator tasks. Similarly, it works if I save my password using "passwd -R". We would like to continue to require public key auth because it is more secure (our public keys are from smartcards, so it's effectively two-factor authentication). I've already confirmed that storing the passwd with "passwd -R" works. I have not tried using cyglsa-config -- would that help? My understanding is that local access would work but access to network resources would not. I would think scheduled tasks are local so it should work but did not want to modify my system yet without some feedback from cygwin experts :) Also, is there another way I might obtain the proper privs/session token, WITHOUT storing the password permanently? I noticed that running "passwd -R" doesn't help with the CURRENT ssh session; i.e. I would have to logout and login again. Finally, the obvious way of checking if the proper privileges are present is simply trying the "schtasks" command and seeing if it fails by checking the exit status. I'm just wondering (for academic reasons) if there's a better way. Perhaps there is some "view my current session token" command? If it matters: $ uname -a CYGWIN_NT-6.1-WOW nissan 2.2.1(0.289/5/3) 2015-08-20 11:40 i686 Cygwin The OS is Server 2008 R2 64-bit. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] lua-ldap 1.1.0-2
The following packages have been uploaded to the Cygwin distribution: * lua-ldap-1.1.0-2 LuaLDAP is a simple interface from Lua to an LDAP client, in fact it is a binding to OpenLDAP. It enables a Lua program to: * Connect to an LDAP server, * Execute any operation (search, add, compare, delete, modify and rename), * Retrieve entries and references of the search result. This release has been built for Lua 5.2. -- Yaakov -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] cgit 0.12-1
The following packages have been uploaded to the Cygwin distribution: * cgit-0.12-1 This is an attempt to create a fast web interface for the git scm, using a builtin cache to decrease server io-pressure. -- Yaakov -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] pdf2djvu 0.9.3-1
The following packages have been uploaded to the Cygwin distribution: * pdf2djvu-0.9.3-1 pdf2djvu creates DjVu files from PDF files. It's able to extract graphics, text, hyperlinks, bookmarks, and metadata. This is an update to the latest upstream release: https://bitbucket.org/jwilk/pdf2djvu/raw/tip/doc/changelog -- Yaakov -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Re: sshd refuses connections since upgrade to 2.4.0-1
On Jan 29 17:05, Patrick Schmitt wrote: > >> P.S. As can be seen from the strace I'm running Agnitum Outpost > >> Firewall Pro and the current EMET - both has never been a problem with > >> Cygwin's sshd (in this installation since May 2010). > > > >An "Access denied" error occurs, apparently in a Windows DLL while > >loading Windows DLLs. It's hard to tell what the reason is, but what > >strikes me as weird is that the crash occurs right after this Agnitum > >thingy has been injected into the process: > >[...] > >Did you try excluding sshd from the checks of that scanner? > > After some debugging and playing with different settings in > Microsoft's Enhanced Mitigation Experience Toolkit > ( https://technet.microsoft.com/de-de/security/jj653751 ) > I managed to determine the following as a "cause" for my sshd problems. > My firewall (Agnitum Outpost Firewall Pro) does not play any role. > > With the current release version 5.2 of EMET on Win7SP1 x64 before > cygwin1-20151203.dll: All mitigations except ASR (Attack Surface > Reduction) could be used (ASR is not needed). > > Since cygwin1-20151203.dll: > The following mitigations must be disabled for sshd to allow connections: > * EAF+ (Export Address Table Access Filtering Plus) > * Stack Pivot > But getting a shell still fails (connection closes before shell starts > ?!). For fully working sshd additionally the following mitigation > must also be disabled: > * Sim Exec Flow (ROP Mitigation) > > The question is what changes/new codepaths in cygwin1.dll trigger the > three mitigations mentioned above since 20151203 ? Well, I have no idea. Cygwin is not doing anything weird (unless you think everything Cygwin is doing to emulate a POSIX environment on Windows is weird). I took a quick glance over the changes between 11/29 and 12/03 and nothing catches my attention. In fact, part of the changes try to clean up code, e.g., using NtCurrentTeb() rather than direct calls to "%fs:4" etc when accessing the TEB. A lot of other changes were only affecting 64 bit Cygwin (e.g., moving the main thread stack to a Cygwin-defined address) If you want to find out, feel free to use git blame on the Cygwin sources. But dependent on the outcome I give no guarantee that this can be changed back. You might want to excempt the Cygwin DLL from the scanner if the scanner is not grok'ing that Cygwin is doing nothing bad. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat signature.asc Description: PGP signature
Re: sshd refuses connections since upgrade to 2.4.0-1
Patrick Schmitt writes: > P.S. I'm sorry for breaking threading, but apparently my freemail > provider (gmx.net) does not allow sending email to addresses longer > than 60 characters. The subscription confirmation addresses for the > list (ezmlm) are at least in my case longer than that (here 88 chars) > :( Then use gmane.org already. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Python stackdump on "succesful" exit after import of python-requests
Hello, I am having a strange issue with Python 2.7 on cygwin. Whenever a script of mine imports 'requests' (python-requests installed via cygwin installer), after it closes I get an "Aborted" message and a stack dump. This consistently causes the issue: $ python Python 2.7.10 (default, Jun 1 2015, 18:17:45) [GCC 4.9.2] on cygwin Type "help", "copyright", "credits" or "license" for more information. >>> import requests >>> exit() Aborted (core dumped) And here is the stackdump $ cat python2.7.exe.stackdump Stack trace: Frame Function Args 0028C868 61033A23 (0244, EA60, 00A4, 0028C8D8) 0028C998 610F27E2 (00C8, 00CC, 00B8, 6111295F) This is what gdb says: (gdb) r Starting program: /usr/bin/python [New Thread 8744.0x1ca0] [New Thread 8744.0x24f4] [New Thread 8744.0x192c] [New Thread 8744.0x11f0] Python 2.7.10 (default, Jun 1 2015, 18:17:45) [GCC 4.9.2] on cygwin Type "help", "copyright", "credits" or "license" for more information. >>> import requests [New Thread 8744.0x2380] >>> quit() Program received signal SIGABRT, Aborted. 0x65c63de4 in Py_Exit () at /usr/src/debug/python-2.7.10-1/Python/pythonrun.c:1780 1780 exit(sts); (gdb) bt #0 0x65c63de4 in Py_Exit () at /usr/src/debug/python-2.7.10-1/Python/pythonrun.c:1780 #1 0x770ff8d1 in ntdll!ZwWaitForSingleObject () from /cygdrive/c/Windows/SysWOW64/ntdll.dll #2 0x765014b9 in WaitForSingleObjectEx () from /cygdrive/c/Windows/syswow64/KERNELBASE.dll #3 0x02f8 in ?? () #4 0x in ?? () (gdb) continue Continuing. [New Thread 8744.0x25c4] 3 [main] python2.7 8744 cygwin_exception::open_stackdumpfile: Dumping stack trace to python2.7.exe.stackdump [Thread 8744.0x24f4 exited with code 34304] [Thread 8744.0x25c4 exited with code 34304] [Thread 8744.0x2380 exited with code 34304] [Thread 8744.0x192c exited with code 34304] [Inferior 1 (process 8744) exited with code 0103000] Any ideas? Thanks, Robert Martens ADMS cygcheck.out Description: cygcheck.out -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Various X.Org components
The following packages have been uploaded to the Cygwin distribution: * kbproto-1.0.7-1 * libfontenc-1.1.3-1 * libFS-1.0.7-1 * libXaw-1.0.13-1 * libXi-1.7.6-1 * libXrandr-1.5.0-1 * libXrender-0.9.9-1 * libXt-1.1.5-1 * libxkbfile-1.0.9-1 * rendercheck-1.5-1 * setxkbmap-1.3.1-1 * smproxy-1.0.6-1 * twm-1.0.9-1 * x11perf-1.6.0-1 * xcmsdb-1.0.5-1 * xcompmgr-1.1.7-1 * xditview-1.0.4-1 * xdpyinfo-1.3.2-1 * xev-1.2.2-1 * xgc-1.0.5-1 * xhost-1.0.7-1 * xinput-1.6.2-1 * xkbcomp-1.3.1-1 * xkbevd-1.1.4-1 * xkbprint-1.0.4-1 * xkeyboard-config-2.17-1 * xlsatoms-1.1.2-1 * xlsfonts-1.0.5-1 * xmag-1.0.6-1 * xmh-1.0.3-1 * xmodmap-1.0.9-1 * xorg-cf-files-1.0.6-1 * xorg-docs-1.7.1-1 These are the latest upstream updates to the X.Org X11 components, comprising mostly of code cleanups and minor bug fixes. Separate -devel packages have been added for xkbcomp and xkeyboard-config. -- Yaakov -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Issues with ACL settings after updating to the latest cygwin.dll
I've discovered that when I use cvs to pull a module, the security settings on the created files and directories are incorrect. When I view the security settings of the files, I noticed an invalid "NULL SID" group permission was added. If I delete this value, I can properly execute the file, but if I leave it there, the file I'm trying to execute will not run. NOTE: If I use wincvs, the files are fine. This only happens within the cygwin environment. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
cygwin_conv_path sometimes removes trailing slash
I'm using cygwin_conv_path to convert Win32 paths to POSIX paths, and
I'm puzzled by the conversion
d:/ --> /cygdrive/d
without the trailing slash. By contrast, we have
d:/foo/ --> /cygdrive/d/foo/
Is the removal of the trailing slash in the first example a deliberate
design decision? I find it counter-intuitive.
My tests are essentially based on the example at the end of
https://cygwin.com/cygwin-api/func-cygwin-conv-path.html:
#include
#include
#include
int
main ()
{
wchar_t *win32 = L"d:/";
ssize_t size;
char *posix;
size = cygwin_conv_path (CCP_WIN_W_TO_POSIX, win32, NULL, 0);
if (size < 0)
perror ("cygwin_conv_path");
else
{
posix = (char *) malloc (size);
if (cygwin_conv_path (CCP_WIN_W_TO_POSIX, win32, posix, size))
perror ("cygwin_conv_path");
}
printf ("%s\n", posix);
}
Ken
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
