RE: Possible Security Hole in SSHD w/ CYGWIN?
Thank you for the response.. That is the problem though, it is not an error I am getting (that is in fact the issue is that I SHOULD be getting a "permission denied" but I am not). The problem is that I have access to things that I should not. Since this is plain text only I can't post a SS of the open session that is shown in Computer Management->Shared Folders->Sessions, but it shows the privileged server account "cyg_server" instead of the user that I am accessing the share as (the user I SSH'd in as). And I just found out with further testing that when I connect using a password to Cygwin SSHD server, then access the file share, I have the correct permissions and it shows an open session as the user I connected as like it should. So it is something specifically that happens when connecting using public key authentication. Here is an example though: [user]@[client machine] ~$ ssh [user]@[SSH server].[domain] Enter passphrase for key '/home/[user]/.ssh/id_dsa': Last login: Mon Feb 8 21:41:51 2016 from [client machine] [user]@[SSH server] //[file server]/[share] $ ls -l total 8 drwxrwx---+ 1 [admin user] Domain Users0 Feb 7 18:29 [private folder] drwxrwx---+ 1 [user]Domain Users0 Feb 7 17:31 [public folder] [user]@[SSH server] //[file server]/[share] $ ls -l [private folder] total 8 -rwxrwx---+ 1 [admin user] Domain Users 6070 Feb 6 22:50 [private file] Please note that the user on the client machine and the user I am connecting as on the SSH server are the same user account (a domain account). The [admin account] is a domain account w/ domain admin privileges. The private folder has NTFS ACLs set on it to prevent anyone other than domain admins from listing the contents (as does the file inside it have ACLs preventing anyone other than domain admins from reading it). The public folder is listable by any domain users. Now what happens when I login with a password instead of a key: [user]@[client machine] ~$ ssh [user]@[SSH server].[domain] [user]@[SSH server].[domain]'s password: Last login: Tue Feb 9 20:18:44 2016 from [client machine] [user]@[SSH server] //[file server]/[share] $ ls -l total 8 drwxr-x--- 1 Unknown+User Unknown+Group0 Feb 7 18:29 [private folder] drwxrwx---+ 1 [user]Domain Users 0 Feb 7 17:31 [public folder] [user]@[SSH server] //[file server]/[share] $ ls -l [private folder] ls: cannot open directory [private folder]: Permission denied The behavior the second time is what I would expect the first time. Also in the second scenario, Computer Management->Shared Folders->Sessions shows the proper user being connected (the user I SSH'd in as) instead of the privileged server account "cyg_server". Thanks again for any help - much appreciated David -Original Message- From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of Stephen John Smoogen Sent: Tuesday, February 09, 2016 8:57 PM To: cygwin@cygwin.com Subject: Re: Possible Security Hole in SSHD w/ CYGWIN? On 9 February 2016 at 21:39, David Willis wrote: > Just to add an update to this, it appears that processes run from the > shell while logged into the CYGWIN SSHD server are run as the correct user - i.e. > I run a ping or cat a file and pipe it to less, and check Task Manager > on the SSHD server, and those processes show as being run as the user > I SSH'd in as, the way it should be. > > So it looks like this bug is specifically when accessing files or > directory contents. I literally run a "ls -l" command from the local > CYGWIN shell on the SSHD server, against a file share that I have no > access to, and get a permission denied. I run the exact same command, > SSH'd into that same box as the same user against the same file share, > and this time I can list the directory contents. Same results with "cat"ing files in those directories. > What gives? > > Any help on this VERY much appreciated!!! > In general, you need to be able to cut and paste the errors you are seeing versus using words to describe them. There are several different things that what you are describing could look like so without that extra data it is hard to figure out how to duplicate what you might be seeing. -- Stephen J Smoogen. -- 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 -- 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: Possible Security Hole in SSHD w/ CYGWIN?
On 9 February 2016 at 21:39, David Willis wrote: > Just to add an update to this, it appears that processes run from the shell > while logged into the CYGWIN SSHD server are run as the correct user - i.e. > I run a ping or cat a file and pipe it to less, and check Task Manager on > the SSHD server, and those processes show as being run as the user I SSH'd > in as, the way it should be. > > So it looks like this bug is specifically when accessing files or directory > contents. I literally run a "ls -l" command from the local CYGWIN shell on > the SSHD server, against a file share that I have no access to, and get a > permission denied. I run the exact same command, SSH'd into that same box as > the same user against the same file share, and this time I can list the > directory contents. Same results with "cat"ing files in those directories. > What gives? > > Any help on this VERY much appreciated!!! > In general, you need to be able to cut and paste the errors you are seeing versus using words to describe them. There are several different things that what you are describing could look like so without that extra data it is hard to figure out how to duplicate what you might be seeing. -- Stephen J Smoogen. -- 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: Possible Security Hole in SSHD w/ CYGWIN?
Just to add an update to this, it appears that processes run from the shell while logged into the CYGWIN SSHD server are run as the correct user - i.e. I run a ping or cat a file and pipe it to less, and check Task Manager on the SSHD server, and those processes show as being run as the user I SSH'd in as, the way it should be. So it looks like this bug is specifically when accessing files or directory contents. I literally run a "ls -l" command from the local CYGWIN shell on the SSHD server, against a file share that I have no access to, and get a permission denied. I run the exact same command, SSH'd into that same box as the same user against the same file share, and this time I can list the directory contents. Same results with "cat"ing files in those directories. What gives? Any help on this VERY much appreciated!!! Thanks, David -Original Message- Sent: Tuesday, February 09, 2016 7:56 AM To: 'cygwin@cygwin.com' Subject: RE: Possible Security Hole in SSHD w/ CYGWIN? Sorry for starting a new thread w/ the reply, forgot to subscribe before posting my question yesterday... Thanks for getting back so quickly Yes, I have read that page pretty much from top to bottom, and as far as I know I have configured sshd and the user accounts correctly. I have a non-privileged, disabled account named "sshd", as well as a privileged account called "cyg_server". Privilege separation seems to be working fine - i.e. when the request for a connection comes in the process is running as "sshd", then it spawns a privileged process running as "cyg_server" once the user is authenticated. However no I am not logging in with a password; I have setup public key authentication. And the user I'm being connected as (as seen from the file share server) is not the "sshd" user account, it is the privileged "cyg_server" user account. Although that account has no rights to logon interactively or thru Terminal Services, it is a privileged account on the file server (because the file server is also running CYGWIN and thus must allow privileged rights to that account as well). I should clarify that in my case, cyg_server is a domain account (not a local account). And the way I can verify, is that I have a folder on that share that the user I am authenicating as does not have rights do view, but cyg_server does (because Administrators on that server do), and when I connect as my user via SSHD to any one of my other machines on the domain running CYGWIN, I can then navigate to and read the contents of that file share when I shouldn't be able to. If I try to do the same thing, from the same account, but on my machine locally without connecting to any other CYGWIN SSH server, I get a "Permission denied", which is what I would expect. Thank you for your help on this. David -- Did you read https://cygwin.com/cygwin-ug-net/ntsec.html, configured sshd and the user accounts correctly and are logging in with a password using either of the methods described? FWIW, I'm seeing the connected user as the one that I logged into via ssh. In fact the sshd user account doesn't have any network access rights anyway, so I couldn't connect to any network share if that acount would be used. Regards, Achim. -Original Message- Sent: Monday, February 08, 2016 10:43 PM To: 'cygwin@cygwin.com' Subject: Possible Security Hole in SSHD w/ CYGWIN? Hello, I noticed that when connecting via SSH to a CYGWIN-based SSHD server, if the user connects to a network share (i.e. they CD to the share UNC path in the BASH/CYGWIN shell), they get connected as the privileged server user account created for privilege separation when SSHD is configured w/ ssh-host-config. In other words, they have the rights of that account, and if that account happens to be a domain admin (or even a local admin on the box hosting the share), that user has full admin rights on that share, when in fact they should have the rights assigned to the user account they SSH'd in with. To reproduce, connect via SSH (from either a Linux or CYGWIN/Windows client) to a CYGWIN-based SSHD server using a normal privileged user account (an account preferably that is not an admin either on the client or server machine). Once connected to the Windows SSHD server, CD to a UNC path of a network share. Once CD'd to that path, check Computer Management on that server, and go to Shares->Open Sessions, and you will see that the user connected is the privileged SSHD server account (and it will obviously show as being connected from the machine you are SSH'd into). Anyone else ever notice this before? Running OpenSSH v7 BTW, SSH client is Win7, SSH server Win7, file share server Win2008R2 Thanks, David -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http:/
[ANNOUNCEMENT] enca 1.18-1
The following packages have been uploaded to the Cygwin distribution: * enca-1.18-1 * libenca0-1.18-1 * libenca-devel-1.18-1 * libenca-doc-1.18-1 Enca is an Extremely Naive Charset Analyser. It detects character set and encoding of text files and can also convert them to other encodings. The charset detecing functionality is also available as a library. This is the initial release for Cygwin. -- 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: Last Version of Cygwin for XP
Greetings, Jonathan Brenster! > I saw a post a number of months back indicating that XP support would > start to phase out in Dec '15. > Is there a last version or intended last version that still officially > supports it? > I understand XP is well past EOL, just looking for the info. There was no set date announced yet. -- With best regards, Andrey Repin Wednesday, February 10, 2016 05:07:54 Sorry for my terrible english... -- 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: Issues with ACL settings after updating to the latest cygwin.dll
Greetings, xnor! >>The permissions must *not* be reordered. If Cygwin creates permissions >>incorrectly it's one thing, but the order to emulate POSIX permissions >>is non-canonical. Reordering them will break them. >> >>Please provide the exact output from icacls. > They *have* to be reordered to be modifiable in Windows/Explorer. In > other words, if I want to change permission the new ACL behavior ensures > that it breaks the Cygwin permissions? It was always the case. Permissions are NOT REQUIRED to be ordered in a specific way, but Explorer is only capable of editing them in the only one way. Means, Explorer is deficient. Explorer. Not Windows. Windows is perfectly capable of handling the Cygwin ACL in the intended way. -- With best regards, Andrey Repin Wednesday, February 10, 2016 05:05:14 Sorry for my terrible english... -- 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: Last Version of Cygwin for XP
On 2016-02-09 19:37, Jonathan Brenster wrote: I saw a post a number of months back indicating that XP support would start to phase out in Dec '15. Is there a last version or intended last version that still officially supports it? Support for XP has yet to be removed but that is subject to change at any time. -- 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
Last Version of Cygwin for XP
Hi, I saw a post a number of months back indicating that XP support would start to phase out in Dec '15. Is there a last version or intended last version that still officially supports it? I understand XP is well past EOL, just looking for the info. Thanks -- 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: subversion 1.9.3-1 segfault
On 02/09/2016 08:55 PM, Andrey Repin wrote:
> Greetings, Greg Chicares!
>
>> 'svn' segfaulted on a routine command:
>
>> zsh: segmentation fault (core dumped)
>
> So, was it svn or zsh that crashed?
It was svn that crashed. I was running it in zsh, which trapped the
segfault and printed this:
zsh: segmentation fault (core dumped)
Usually, zsh prints the failed command at the end of that message,
as in this session:
$bash -c 'inf() { inf; }; inf'
zsh: segmentation fault (core dumped) bash -c 'inf() { inf; }; inf'
but in this case it did not, and the omission does make the message
potentially confusing. But the stackdump contains:
program=C:\cygwin-lmi\bin\svn.exe, pid 1736, thread main
so it's surely svn that crashed.
--
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
Trunk of 'file' fails to build due to regex error
Hi all.
I'm trying to build the `file` program from trunk, but I'm getting a regex
error that seems to be related to 8-bit character handling in Cygwin.
The error happens when compiling the magicfile:
> file: line 83: regex error 17 for `[=.<>|!^▒]{79}', (illegal byte sequence)
I currently have little idea where to start in investigating this error. I'd be
glad if someone could help.
See for upstream bug where there's a link
to which seems to be about
a very similar (if not the same) error, but more than 2 years ago.
--
David Macek
smime.p7s
Description: S/MIME Cryptographic Signature
Re: subversion 1.9.3-1 segfault
Greetings, Greg Chicares! > 'svn' segfaulted on a routine command: > zsh: segmentation fault (core dumped) So, was it svn or zsh that crashed? -- With best regards, Andrey Repin Tuesday, February 9, 2016 23:54:35 Sorry for my terrible english... -- 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[2]: Issues with ACL settings after updating to the latest cygwin.dll
Not sure what Transmission is, but files downloaded with POSIX tools are usually not executable. For instance, download Cygwin's setup-x86.exe with wget. Then try to execute it. It won't since the permissions are set according to your umask and without execute permissions, e.g., 0644. This is normal. The behavior has changed with the ACL change in Cygwin and I would not consider that "normal". The warning from Windows is not normal. I realize that the previous implementation was already problematic and messed with permissions but I did not notice it since it never denied executing executables. The permissions must *not* be reordered. If Cygwin creates permissions incorrectly it's one thing, but the order to emulate POSIX permissions is non-canonical. Reordering them will break them. Please provide the exact output from icacls. They *have* to be reordered to be modifiable in Windows/Explorer. In other words, if I want to change permission the new ACL behavior ensures that it breaks the Cygwin permissions? Here is the output from icacls /saveacl for some file: D:P(D;;RPWPDTRC;;;S-1-0-0)(A;;0x1f019f;;;S-1-5-21-559282050-488988736-2019639472-1001)(D;;WP;;;AU)(D;;WP;;;SY)(D;;WP;;;BA)(D;;WP;;;BU)(A;;FR;;;S-1-5-21-559282050-488988736-2019639472-513)(A;;0x1201bf;;;AU)(A;;0x1201bf;;;SY)(A;;0x1201bf;;;BA)(A;;0x1200a9;;;BU)(A;;FR;;;WD) After letting Windows fix the order: D:PAI(D;;RPWPDTRC;;;S-1-0-0)(D;;WP;;;AU)(D;;WP;;;SY)(D;;WP;;;BA)(D;;WP;;;BU)(A;;0x1f019f;;;S-1-5-21-559282050-488988736-2019639472-1001)(A;;FR;;;S-1-5-21-559282050-488988736-2019639472-513)(A;;0x1201bf;;;AU)(A;;0x1201bf;;;SY)(A;;0x1201bf;;;BA)(A;;0x1200a9;;;BU)(A;;FR;;;WD) Here is what's "normal" for Windows if I create a file under a new folder on C: in Explorer: D:AI(A;ID;FA;;;BA)(A;ID;FA;;;SY)(A;ID;0x1200a9;;;BU)(A;ID;0x1301bf;;;AU) Strangely enough this is displayed as "-rwxrwx---+ MyUser None" with `ls -l` even though my user is in the group Administrators. Here is what I would expect: MyUser is in the group Administrators. Given the inherited permissions above a Windows-created file should be shown as "-rwxrwxr--+ MyUser Administrators"? After chmod 664 I would expect this: - still inherit all the permissions - add permission MyUser DENY execute - add permission Administrators DENY execute - add permission Everyone ALLOW read Instead Cygwin copies all permissions, drops the inheritance, copies them again, adds None, adds NULL SID ... After a consecutive chmod 770 I would expect the above non-inherited permissions to be removed again. -- 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
subversion 1.9.3-1 segfault
'svn' segfaulted on a routine command: /lmi/mirror/lmi[0]$svn status --show-updates svn: E170013: Unable to connect to a repository at URL 'http://svn.savannah.nongnu.org/svn/lmi/lmi/trunk' svn: E000104: Error running context: Connection reset by peer svn update Updating '.': zsh: segmentation fault (core dumped) The command worked as expected when I reran it (after 'svn cleanup'): /lmi/mirror/lmi[0]$svn update svn: E155004: Run 'svn cleanup' to remove locks (type 'svn help cleanup' for details) svn: E155004: Working copy '/lmi/mirror/lmi' locked. svn: E155004: '/lmi/mirror/lmi' is already locked. /lmi/mirror/lmi[1]$svn cleanup /lmi/mirror/lmi[0]$svn update Updating '.': At revision 6500. It's working now, and I can't reproduce the problem, but I thought I should report it anyway. I've attached cygcheck -s -v -r output and copied 'svn.exe.stackdump' below. Exception: STATUS_ACCESS_VIOLATION at eip= eax=200C61B8 ebx=200A8DE8 ecx=0022C39C edx= esi= edi=0011 ebp=200C01A0 esp=0022C35C program=C:\cygwin-lmi\bin\svn.exe, pid 1736, thread main cs=001B ds=0023 es=0023 fs=003B gs= ss=0023 Stack trace: Frame Function Args 200C01A0 (, , 6C1D5580, 200A0E90) 200A8DE8 (0002, 200A8DE8, 2009EDC0, 200AAEC8) 2009F5D8 (6C701180, 6C701160, , 2009F978) 2009EDC0 2009F628 (, 20052794, 200AAF00, ) 20052790 200C81B8 (2004D788, 200430F4, , 20052C08) 200430F0 2009EDC0 (2003EF00, 20038D6C, 20054CB0, ) 20038D68 20052790 (, , 20038E88, ) End of stack trace Cygwin Configuration Diagnostics Current System Time: Tue Feb 09 17:14:18 2016 Windows XP Professional Ver 5.1 Build 2600 Service Pack 3 Path: C:\opt\lmi\local\bin C:\opt\lmi\local\lib C:\cygwin-lmi\usr\local\bin C:\cygwin-lmi\bin C:\cygwin-lmi\bin C:\cygwin-lmi\usr\sbin C:\cygwin-lmi\sbin C:\cygwin-lmi\usr\local\bin C:\cygwin-lmi\bin C:\WINDOWS\system32 C:\WINDOWS C:\WINDOWS\System32\Wbem C:\Program Files\Support Tools C:\BC5\BIN Output from C:\cygwin-lmi\bin\id.exe UID: 197611(earl) GID: 197121(None) 197121(None)544(Administrators) 545(Users) 4(INTERACTIVE) 11(Authenticated Users) 4095(CurrentSession) 66048(LOCAL) SysDir: C:\WINDOWS\system32 WinDir: C:\WINDOWS HOME = '/home/earl' PWD = '/home/earl' USER = 'earl' ALLUSERSPROFILE = 'C:\Documents and Settings\All Users' APPDATA = 'C:\Documents and Settings\earl\Application Data' CLIENTNAME = 'Console' COMMONPROGRAMFILES = 'C:\Program Files\Common Files' COMPUTERNAME = 'ILUVATAR' COMSPEC = 'C:\WINDOWS\system32\cmd.exe' FP_NO_HOST_CHECK = 'NO' HOMEDRIVE = 'C:' HOMEPATH = '\Documents and Settings\earl' LOGONSERVER = '\\ILUVATAR' NUMBER_OF_PROCESSORS = '8' OS = 'Windows_NT' PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH' PROCESSOR_ARCHITECTURE = 'x86' PROCESSOR_IDENTIFIER = 'x86 Family 6 Model 42 Stepping 1, GenuineIntel' PROCESSOR_LEVEL = '6' PROCESSOR_REVISION = '2a01' PROGRAMFILES = 'C:\Program Files' SESSIONNAME = 'Console' SYSTEMDRIVE = 'C:' SYSTEMROOT = 'C:\WINDOWS' USERDOMAIN = 'ILUVATAR' USERNAME = 'earl' USERPROFILE = 'C:\Documents and Settings\earl' WINDIR = 'C:\WINDOWS' TERM = 'xterm' LOGNAME = 'earl' SHLVL = '1' OLDPWD = '/usr/bin' LANG = 'en_US.UTF-8' TZ = 'UCT' SHELL = '/bin/zsh' PROFILEREAD = 'true' ORIGINAL_PATH = '/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/Program Files/Support Tools:/cygdrive/c/BC5/BIN' INFOPATH = '/usr/local/info:/usr/share/info:/usr/info' TMP = '/tmp' TEMP = '/tmp' HOSTNAME = 'iluvatar' PS1 = '%m%# ' coefficiency = '--jobs=6 --output-sync=recurse' LC_COLLATE = 'C.UTF-8' _ = '/usr/bin/cygcheck' HKEY_CURRENT_USER\Software\Cygwin HKEY_CURRENT_USER\Software\Cygwin\Program Options HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MenuOrder\Start Menu\Programs\Cygwin (default) = (unsupported type) HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\Installations (default) = '\??\C:\cygwin-lmi' HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\Program Options HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\setup (default) = 'C:/cygwin-lmi' obcaseinsensitive set to 1 Cygwin installations found in the registry: System: Key: 18c9af28b2eb9e16 Path: C:\cygwin-lmi c: hd NTFS 12276Mb 86% CP CS UN PA FC d: cd N/AN/A C:\opt\lmi\MinGW-4_9_1 /MinGW_ userbinary C:\cache_for_lmi/cache_for_lmi userbinary C:\lmi /lmiuserbinary C:\opt\lmi /opt/lmiuserbinary C:\cygwin-lmi / system binary,auto C:\cygwin-lmi\bin /usr/binsystem binary,auto C:\cygwin-lmi\lib /usr/libsystem binary,auto cygdrive prefix /cygdrive user
Re: Downloading Cygwin version 1.7
On 09/02/2016 16:28, Erik Soderquist wrote:
On Tue, Feb 9, 2016 at 10:04 AM, Michele Modolo wrote:
Hello,
I'd like to install the latest version of Oracle Enterprise Manager
(13c) for evaluation purposes. Oracle states that it "is certified and
supported with Cygwin 1.7" so I'd like to install Cygwin 1.7.
The current version of Cygwin is 2.4.1 and it seems there's currently
no way to find the 1.7 version (which is the only one officially
supported by Oracle as stated above) in your official website. Even if
it (really) seems to be awkward...would you have any clue for me to be
able to find and istall an outdated version?
This is copy/pasted from another email on this list I happened to
remember and be able to find again:
{quote}
If you wish to download the old DLL + the old packages, you can obtain
them both with the "Cygwin time machine."
http://www.fruitbat.org/Cygwin/#cygwintimemachine
{quote}
-- Erik
Michele,
please also note that if it works with last 1.7.x
than almost surely works with with any following 2.x
versions.
Regards
Marco
--
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: Possible Security Hole in SSHD w/ CYGWIN?
Sorry for starting a new thread w/ the reply, forgot to subscribe before posting my question yesterday... Thanks for getting back so quickly Yes, I have read that page pretty much from top to bottom, and as far as I know I have configured sshd and the user accounts correctly. I have a non-privileged, disabled account named "sshd", as well as a privileged account called "cyg_server". Privilege separation seems to be working fine - i.e. when the request for a connection comes in the process is running as "sshd", then it spawns a privileged process running as "cyg_server" once the user is authenticated. However no I am not logging in with a password; I have setup public key authentication. And the user I'm being connected as (as seen from the file share server) is not the "sshd" user account, it is the privileged "cyg_server" user account. Although that account has no rights to logon interactively or thru Terminal Services, it is a privileged account on the file server (because the file server is also running CYGWIN and thus must allow privileged rights to that account as well). I should clarify that in my case, cyg_server is a domain account (not a local account). And the way I can verify, is that I have a folder on that share that the user I am authenicating as does not have rights do view, but cyg_server does (because Administrators on that server do), and when I connect as my user via SSHD to any one of my other machines on the domain running CYGWIN, I can then navigate to and read the contents of that file share when I shouldn't be able to. If I try to do the same thing, from the same account, but on my machine locally without connecting to any other CYGWIN SSH server, I get a "Permission denied", which is what I would expect. Thank you for your help on this. David -- Did you read https://cygwin.com/cygwin-ug-net/ntsec.html, configured sshd and the user accounts correctly and are logging in with a password using either of the methods described? FWIW, I'm seeing the connected user as the one that I logged into via ssh. In fact the sshd user account doesn't have any network access rights anyway, so I couldn't connect to any network share if that acount would be used. Regards, 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
Re: Downloading Cygwin version 1.7
On Tue, Feb 9, 2016 at 10:04 AM, Michele Modolo wrote:
> Hello,
>
> I'd like to install the latest version of Oracle Enterprise Manager
> (13c) for evaluation purposes. Oracle states that it "is certified and
> supported with Cygwin 1.7" so I'd like to install Cygwin 1.7.
>
> The current version of Cygwin is 2.4.1 and it seems there's currently
> no way to find the 1.7 version (which is the only one officially
> supported by Oracle as stated above) in your official website. Even if
> it (really) seems to be awkward...would you have any clue for me to be
> able to find and istall an outdated version?
This is copy/pasted from another email on this list I happened to
remember and be able to find again:
{quote}
If you wish to download the old DLL + the old packages, you can obtain
them both with the "Cygwin time machine."
http://www.fruitbat.org/Cygwin/#cygwintimemachine
{quote}
-- Erik
--
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
Downloading Cygwin version 1.7
Hello, I'd like to install the latest version of Oracle Enterprise Manager (13c) for evaluation purposes. Oracle states that it "is certified and supported with Cygwin 1.7" so I'd like to install Cygwin 1.7. The current version of Cygwin is 2.4.1 and it seems there's currently no way to find the 1.7 version (which is the only one officially supported by Oracle as stated above) in your official website. Even if it (really) seems to be awkward...would you have any clue for me to be able to find and istall an outdated version? Thank you, regards -- 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[3]: Issues with ACL settings after updating to the latest cygwin.dll
On Feb 8, 2016 1:33 PM, "xnor" wrote: > > >> I have the same problem with Transmission. > > Sorry for another mail, but I need to make another last correction: > It's not Transmission specific. A simple > $ cd /cygdrive/path/to/download/dir > $ touch test > will result in the same broken permissions for test. > > Doing this in $HOME will result in these Windows permissions: > NULL SID > Everyone > > Nobody (actually non existent S-1-5-21-...) > > There are also no warnings and no prompt to re-order permissions. > > > File permission for an older file (created before cygwin ACL changes): > Everyone > > Nobody (actually non existent S-1-5-21-...) > > > So the new ACL implementation simply messes up in directories with non-cygwin > permissions. > > > > -- > 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 > Thanks xnor for documenting the issue! I've been on travel and didn't have access to my cygwin installation. In my case, I have to use CVS to download source code and executables. Once a file is downloaded, the permissions are set. Each file created using the new ACL features has the NUL SID set and this in turn in fine for regular files, but those that have an execution bit set will not run unless I open their properties in Wnidows, change the security permissions (which states there is a error). -- 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: C++11 thread_local implementation issue on Cygwin/AMD64
On 19 May 2015 at 10:52, Václav Haisman wrote:
> On 19 January 2015 at 15:42, Václav Haisman wrote:
>>
>> Hi.
>>
>> I have hit an issue with thread-local storage variables on
>> Cygwin/AMD64, I do not see it with Cygwin/i686.
>>
>> I am having linking issues when using `thread_local` keyword in Cygwin
>> with its GCC 4.8.3 and GCC 4.9.2. This is derived from log4cplus. The
>> test case is split into three files:
>>
>> File def.hxx:
>>
>>
>> #include
>>
>> namespace N
>> {
>> struct S { std::string str; };
>> // extern declaration in a header
>> extern thread_local S * ptd;
>>
>> // accessing the extern declared ptd here
>> inline
>> S * get_ptd ()
>> {
>> if (! ptd)
>> ptd = new S;
>> return ptd;
>> }
>> } // namespace N
>>
>>
>> File def.cxx:
>>
>>
>> #include "def.hxx"
>>
>> namespace N
>> {
>> // definition of ptd
>> thread_local S * ptd = nullptr;
>> } // namespace N
>> ~~~
>>
>> File use.cxx:
>>
>>
>> #include "def.hxx"
>>
>> namespace N
>> {
>> __declspec(dllexport)
>> void * foo ()
>> {
>> // invoking inline get_ptd() function to get the value in ptd
>> return get_ptd ();
>> }
>> }
>>
>>
>> Now, when I compile each .cxx with `g++ -std=gnu++11
>> -fvisibility=hidden -c use.cxx def.cxx` and then try to link with `g++
>> -shared -o cygtest.dll use.o def.o`, I get the following error from
>> linker:
>>
>>
>> use.o:use.cxx:(.text$_ZTWN1N3ptdE[_ZTWN1N3ptdE]+0x15): relocation
>> truncated to fit: R_X86_64_PC32 against undefined symbol `TLS init
>> function for N::ptd'
>> collect2: error: ld returned 1 exit status
>>
>>
>> The nm -C ./def.o output confirms that:
>>
>>
>> `--> nm -C ./def.o
>> b .bss
>> d .data
>> r .rdata
>> r .rdata$zzz
>> t .text
>> 0008 r __emutls_t._ZN1N3ptdE
>> D __emutls_v._ZN1N3ptdE
>> r std::piecewise_construct
>>
>>
>> As you can see, the ptd thread-local variable initialization function
>> is not defined anywhere. The use.o references this initialization
>> function (see bottom of the listing):
>>
>>
>> `--> nm -C ./use.o
>> b .bss
>> d .data
>> i .drectve
>> p .pdata
>> p .pdata$_ZN1N1SC1Ev
>> p .pdata$_ZN1N7get_ptdEv
>> p .pdata$_ZTWN1N3ptdE
>> r .rdata
>> r .rdata$.refptr.__emutls_v._ZN1N3ptdE
>> r .rdata$.refptr._ZTHN1N3ptdE
>> r .rdata$zzz
>> R .refptr.__emutls_v._ZN1N3ptdE
>> R .refptr._ZTHN1N3ptdE
>> t .text
>> t .text$_ZN1N1SC1Ev
>> t .text$_ZN1N7get_ptdEv
>> t .text$_ZTWN1N3ptdE
>> A .weak._ZTHN1N3ptdE._ZN1N1SC1Ev
>> r .xdata
>> r .xdata$_ZN1N1SC1Ev
>> r .xdata$_ZN1N7get_ptdEv
>> r .xdata$_ZTWN1N3ptdE
>> U __emutls_get_address
>> U __emutls_v._ZN1N3ptdE
>> U __gxx_personality_seh0
>> U __real__ZdlPv
>> U __real__Znwm
>> U _Unwind_Resume
>> U operator delete(void*)
>> T N::S::S()
>> T N::foo()
>> T N::get_ptd()
>> U std::basic_string,
>> std::allocator >::basic_string()
>> U operator new(unsigned long)
>> r std::piecewise_construct
>> w TLS init function for N::ptd
>> T TLS wrapper function for N::ptd
>>
>>
>> Now, this code seems to work well on Linux with both GCC and Clang.
>>
>> Is this a GCC problem on Cygwin?
>> Am I using extern thread_local wrong?
>>
>> My experiments show that not using the extern keyword seems to fix the
>> issue. But I am not sure if that does not introduce two ptd
>> thread-local variables in two TUs.
>>
>> See also http://stackoverflow.com/q/28023728/341065
>
>
> This is also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64697.
Annual ping. :)
--
VH
--
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: Latest curl fails with error 55 (Failed sending HTTP request) with specific URL
On Mon, Feb 8, 2016 at 2:22 PM, Yaakov Selkowitz wrote: > On 2016-02-08 06:57, Andrew Clark wrote: >> >> I've been running a simple script that uses curl to generate a token >> from a web service. Up until the last release (7.47.0-2), this had >> been working fine. Now, however, I'm consistently getting >> >> curl: (55) Failed sending HTTP request >> >> The script I have boils down to this curl request: >> >> $ curl --header "$header" >> https://implementation.concursolutions.com/net2/oauth2/accesstoken.ashx >> >> where $header contains >> >> $ echo "$header" >> Authorization: Basic >> Sm9oblNtaXRoQGRhdGFpbnRlbnNpdHlsbGMuY29tOldlbGNvbWUxCg== >> X-ConsumerKey: oEcc7vFraW66kVlr3zWb6i >> >> (these are values for a dummy account with this provider set up to >> allow access to their token service) > > > A separate --header flag should be used for each header that you wish to > set. IOW: > > curl --header "Authorization: Basic $AUTH" --header "X-ConsumerKey: $KEY" > $URL > > -- > 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 > Thanks! Passing two header flags did the trick. -- 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 interaction with desktop not working
On 2/9/2016 4:49 AM, Aijaz Baig wrote: Hello I am SSH'ing into a windows 10 box from a Linux box. I've configured sshd on the windows box and I can properly SSH into it. X11 forwarding also works perfectly after having installed Xming on windows (not that it matters with this problem anyways). However I am unable to open any windows application from the Linux box. I would like to open the windows app locally in the windows box (or to rephrase it, I do not need the UI windows to be opened on the Linux box) I am unable to figure out why it is not working even after selecting "Allow service to interact with desktop". My goal is to invoke windows app from ssh (Linux to Windows). Similar problems earlier were solved by selecting this option but apparently they were on earlier version of windows. Or should I take a different approach? Am I barking at the wrong tree here?? I am keen to hear from input(s) Wrong tree, yes. Microsoft chopped down the tree you want and planted a new one in its place. In short, the restriction was introduced post-XP as it is considered a security hole. There have been sporadic subsequent reports of success to this list but never a clear recipe for getting this to work reliably. And given that this is perceived as a security hole, I doubt you'll find one that doesn't include some significant effort and/or restrictions. If you search around for "Windows station" and "Allow service to interact with desktop", I think you'll find some relevant information. -- Larry _ A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting annoying in email? -- 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: Problem with new acl code and cdrtools
On 2016-02-09 10:06, Ismail Donmez wrote: > Hi Peter, > > On Tue, Feb 9, 2016 at 10:56 AM, Peter Rosin wrote: >> My take on the situation was that you could disable SUN ACLs by telling >> configure that cdrtools should not use aclfromtext(), and that the code >> that backs this was already in place. I.e. that you could get a working >> build recipe w/o any hacking/patching of cdrtools at all. >> >> I might be misunderstanding something though, but if it works and if >> it is considered more of an hack than introducing a cygwin version >> check inside the cdrtools package, then that's not my headache. >> >> Just trying to help... > > If my reply came out as rude, I am sincerely sorry. As you said yes > this would be a way to fix the situation for Cygwin, but I would be > more happy with a pre-processor macro which we can use for this. I didn't think it rude, but it is clear that we disagree about what is a dirty hack and what is generic. Disagreeing isn't necessarily rude :-) Cheers, Peter -- 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 interaction with desktop not working
Hello I am SSH'ing into a windows 10 box from a Linux box. I've configured sshd on the windows box and I can properly SSH into it. X11 forwarding also works perfectly after having installed Xming on windows (not that it matters with this problem anyways). However I am unable to open any windows application from the Linux box. I would like to open the windows app locally in the windows box (or to rephrase it, I do not need the UI windows to be opened on the Linux box) I am unable to figure out why it is not working even after selecting "Allow service to interact with desktop". My goal is to invoke windows app from ssh (Linux to Windows). Similar problems earlier were solved by selecting this option but apparently they were on earlier version of windows. Or should I take a different approach? Am I barking at the wrong tree here?? I am keen to hear from input(s) -- Best Regards, Aijaz Baig -- 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: Problem with new acl code and cdrtools
On Feb 8 13:24, Yaakov Selkowitz wrote:
> On 2016-02-08 08:10, Corinna Vinschen wrote:
> >Alternatively we could allow to use the Solaris ACL functions even if
> >only including sys/acl.h, given some macro:
> >
> > sys/acl.h:
> >
> > #ifdef __USE_OLD_SOLARIS_ACL_FUNCTIONS
> > # include
> > #else
> > [...POSIX definitions...]
> > #endif
>
> Do the functions or typedefs conflict in any way?
No, they don't. However, I encountered a problem when exposing the
Solaris API at the same time as the POSIX API via sys/acl.h. Vim's
autoconf test failed to recognize support for the POSIX API. Try
this entirely harmless (from the POSIX POV) piece of code:
#include
#include
acl_t acl;
int main ()
{
acl = acl_get_file("foo", ACL_TYPE_ACCESS);
return 0;
}
Works fine, but now try this with an additional
#include
You'll get an error message:
$ gcc -c acl.c
acl.c:5:7: error: ‘acl’ redeclared as different kind of symbol
acl_t acl;
^
In file included from acl.c:2:0:
/usr/include/cygwin/acl.h:76:13: note: previous declaration of ‘acl’ was here
extern int acl (const char *__path, int __cmd, int __nentries,
^
The existence of the functions acl and facl is entirely unexpected in
the POSIX context.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
signature.asc
Description: PGP signature
Re: Problem with new acl code and cdrtools
Hi Peter, On Tue, Feb 9, 2016 at 10:56 AM, Peter Rosin wrote: > My take on the situation was that you could disable SUN ACLs by telling > configure that cdrtools should not use aclfromtext(), and that the code > that backs this was already in place. I.e. that you could get a working > build recipe w/o any hacking/patching of cdrtools at all. > > I might be misunderstanding something though, but if it works and if > it is considered more of an hack than introducing a cygwin version > check inside the cdrtools package, then that's not my headache. > > Just trying to help... If my reply came out as rude, I am sincerely sorry. As you said yes this would be a way to fix the situation for Cygwin, but I would be more happy with a pre-processor macro which we can use for this. Anyhow. Thanks, 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: Problem with new acl code and cdrtools
On 2016-02-09 08:56, Ismail Donmez wrote: > Hi, > > On Tue, Feb 9, 2016 at 6:14 AM, Warren Young wrote: >> On Feb 8, 2016, at 9:59 AM, Ismail Donmez wrote: >>> >>> On Mon, Feb 8, 2016 at 6:29 PM, Peter Rosin wrote: On 2016-02-08 14:31, Ismail Donmez wrote: > This is a generic code so I don't want to add a cygwin specific > dependency there. Is there a preprocessor definition for cygwin > version? I could use that to disable HAVE_SUN_ACL for cygwin 2.5+ Pardon me for butting in, but isn't adding a Cygwin version check about as non-generic as it gets? Wouldn't something like this work: .../configure ac_cv_func_aclfromtext=no >>> >>> Thats a hack :) >> >> I don’t know if that smiley means you’re joking or if you’re just trying to >> soften a negative judgement, but Peter’s proposal is as far from a hack as >> it gets. > > What Peter suggests is telling autoconf to assume aclfromtext() does > not exist on the system which is a hack and I already have a hack I > could use. > >> He is proposing that you write an autoconf test that determines if the >> platform has this new ACL behavior. Then in your C code: >> >>#include >>#if HAVE_FUNC_ACLFROMTEXT >># include >>#endif > > I could check for __cygwin__ instead of that which would do the same thing. > > Anyhow the discussion diverged a lot, and for now I'll be using my > simple hack of disabling HAVE_SUN_ACL manually. My take on the situation was that you could disable SUN ACLs by telling configure that cdrtools should not use aclfromtext(), and that the code that backs this was already in place. I.e. that you could get a working build recipe w/o any hacking/patching of cdrtools at all. I might be misunderstanding something though, but if it works and if it is considered more of an hack than introducing a cygwin version check inside the cdrtools package, then that's not my headache. Just trying to help... Cheers, Peter -- 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: Problem with new acl code and cdrtools
On Tue, Feb 9, 2016 at 10:46 AM, Warren Young wrote: > On Feb 9, 2016, at 12:56 AM, Ismail Donmez wrote: >> >> On Tue, Feb 9, 2016 at 6:14 AM, Warren Young wrote: >>> On Feb 8, 2016, at 9:59 AM, Ismail Donmez wrote: Thats a hack :) >>> >>> Peter’s proposal is as far from a hack as it gets. >> >> What Peter suggests is telling autoconf to assume aclfromtext() does >> not exist on the system which is a hack and I already have a hack I >> could use. > > No. Once again, he’s suggesting that you write a *test* that checks whether > aclfromtext() exists here. Hypothesis -> test -> decision is science, not > assumption or hackery. The check would succeed for all versions of Cygwin, the hack part is telling configure to not check for it and assume "no". 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: Problem with new acl code and cdrtools
On Feb 9, 2016, at 12:56 AM, Ismail Donmez wrote: > > On Tue, Feb 9, 2016 at 6:14 AM, Warren Young wrote: >> On Feb 8, 2016, at 9:59 AM, Ismail Donmez wrote: >>> >>> Thats a hack :) >> >> Peter’s proposal is as far from a hack as it gets. > > What Peter suggests is telling autoconf to assume aclfromtext() does > not exist on the system which is a hack and I already have a hack I > could use. No. Once again, he’s suggesting that you write a *test* that checks whether aclfromtext() exists here. Hypothesis -> test -> decision is science, not assumption or hackery. >> #include >> #if HAVE_FUNC_ACLFROMTEXT >> # include >> #endif > > I could check for __cygwin__ instead of that which would do the same thing. Not if it’s Cygwin 1.7.34. -- 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
