Re: Problem with sshd on W7 with 32bit cygwin 3.0
On Mon, Feb 18, 2019 at 09:54:50PM +0100, Corinna Vinschen wrote: > On Feb 18 17:04, Enrico Forestieri wrote: > > On Mon, Feb 18, 2019@03:11:11PM +0100, Corinna Vinschen wrote: > > > > > > Two workarounds for now: > > > > > > - Start sshd as 64 bit Cygwin process. > > > - Utilize https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-nopasswd3 > > > > Thank you. The second method above worked. This is a private network, > > so that is Ok. > > I uploaded new developer snapshots with fixes for this problem: > https://cygwin.com/snapshots/ Please give it a try. Thanks. I can confirm that with this snaspshot sshd works fine without the need for the workaround. -- Enrico -- 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
Very slow start of cygwin-3.0.0-1 (32-bit)
Hello everyone, I am using Cygwin (32-bit) on 64-bit Windows 10 computer. This computer is member of a big AD domain. My account is member of a lot of AD groups. In my configuration there are no /etc/passwd and /etc/group files. The /etc/nsswitch.conf file is empty. I don't use cygserver. I just updated from cygwin-2.11.2-1 to cygwin-3.0.0-1 without changing something else on my computer configuration. With cygwin-2.11.2-1 the startup of a terminal window was fast (about 1 second). With cygwin-3.0.0-1 it takes about 5 minutes. Is this something new and the expected behavior with cygwin-3.0.0-1? Thanks and kind regards, René -- 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
Sqlite 3.23 or better?
When will Cygwin update Sqlite to v3.23 or better (released in 2018/04)? As of Sqlite 3.23 TRUE/FALSE aliases were added. (I searched the archive and could not find this question.) Support in perl, php, etc... also desired. >From a local compile of 3.27.1: ``` $ ./sqlite3 sqlite> select true; true 1 changes: 0 total_changes: 0 sqlite> select false; false 0 sqlite> select true is not false; true is not false 1 changes: 0 total_changes: 0 ``` Current Cygwin Sqlite version is 3.21 and does not recognize TRUE/FALSE: ``` $ sqlite3 sqlite> select true; Error: no such column: true sqlite> select false; Error: no such column: false ``` Any pointers appreciated. -- In Need Of True-th :) -- 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: Sqlite 3.23 or better?
On Tue, 2/19/19, Jan Nijtmans wrote: > Well, > I'm on it! My guess: within a week or so. Great, thanks so much Jan! : )) -- "A smile is the shortest distance between two people." Victor Borge -- 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: Sqlite 3.23 or better?
Op di 19 feb. 2019 om 15:49 schreef iWantToKeepAnon: > > When will Cygwin update Sqlite to v3.23 or better (released in 2018/04)? As > of Sqlite 3.23 TRUE/FALSE aliases were added. (I searched the archive and > could not find this question.) Support in perl, php, etc... also desired. Well, I'm on it!My guess: within a week or so. Regards, Jan Nijtmans -- 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 sshd on W7 with 32bit cygwin 3.0
On Feb 19 11:30, Enrico Forestieri wrote: > On Mon, Feb 18, 2019 at 09:54:50PM +0100, Corinna Vinschen wrote: > > On Feb 18 17:04, Enrico Forestieri wrote: > > > On Mon, Feb 18, 2019@03:11:11PM +0100, Corinna Vinschen wrote: > > > > > > > > Two workarounds for now: > > > > > > > > - Start sshd as 64 bit Cygwin process. > > > > - Utilize https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-nopasswd3 > > > > > > Thank you. The second method above worked. This is a private network, > > > so that is Ok. > > > > I uploaded new developer snapshots with fixes for this problem: > > https://cygwin.com/snapshots/ Please give it a try. > > Thanks. I can confirm that with this snaspshot sshd works fine without > the need for the workaround. Thanks for testing! Corinna -- Corinna Vinschen Cygwin Maintainer signature.asc Description: PGP signature
please help me
I installed ns2.35 for windows 7 package i miss bashrc file and cygwin desktop shortcut shows that couldn't compute FAST_CWD pointer so please show me how to solve this problem and where i get bashrc file -- 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: please help me
>I installed ns2.35 for windows 7 package i miss bashrc file and cygwin >desktop shortcut shows that couldn't compute FAST_CWD pointer so please >show me how to solve this problem and where i get bashrc file https://cygwin.com/faq.html#faq.using.fixing-find_fast_cwd-warnings -- 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
emacs-X11 unstable under cygwin 3.0.0-1
I have found that emacs-X11 (26.1-1) is unstable under cygwin 3.0.0-1. It works fine if I revert to cygwin 2.11.2-1. The symptom is random crashing, generally within the first minute of use. If I get some time I will try strace on it. I have not located a stack dump either - not sure if it's producing one. (I normally start emacs from a .XWinrc menu under X; I am not certain in which directory the X server is running, which presumably would have to do with where a stack dump file would appear.) But I thought it worth the report anyway. The crashes will happen even when just navigating in the emacs buffer, i.e., it does not seem obviously related to some action on (e.g.) files. Regards - Eliot Moss -- 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: Windows to Cygwin username mapping: Domain before local account when duplicate name?
On Fri, Feb 15, 2019 at 3:48 PM Bill Stewart wrote: > This means that when I test getent using the name "Admin", Cygwin > finds the domain group: > > PS C:\> getent -w passwd admin > admin::DOMAINNAME\admin:S-1-5-21-nn-n-n-nn > > I get that this is by design, but .NET finds the local account first, > which is what I was expecting: > > PS C:\> $name = [Security.Principal.NTAccount] "admin" > PS C:\> $sid = $name.Translate([Security.Principal.SecurityIdentifier]) > PS C:\> $sid.Translate([Security.Principal.NTAccount]) > > Value > - > COMPUTERNAME\Admin So then - just to follow up - Cygwin is for sure going to stick with "domain first" when resolving an account name that doesn't include an authority. (a) Is this correct? (b) Is there a particular reason this order was chosen (instead of local first, then domain, i.e., the usual Windows order)? Thanks, Bill -- 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: Get Cygwin home directory path for current user
On Fri, Feb 15, 2019 at 11:09 PM L A Walsh wrote: > Vince, I think What Bill is trying to ask is how does > the cygwin shell might do it (answer: look at the source! ;-)). Or rather more succinctly: "Cygwin, what is the path to the current user's home directory?" IMO it would be simpler for cygpath to have a flag for this so we can simply ask directly instead of collecting stdout from a shell command. But as I noted - requesting it from a shell _does_ work - my thought is simply that this would be a rather useful option to have in cygpath. Regards, Bill -- 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: Windows to Cygwin username mapping: Domain before local account when duplicate name?
On Tue, Feb 19, 2019 at 8:47 AM Bill Stewart wrote: > (a) Is this correct? > > (b) Is there a particular reason this order was chosen (instead of > local first, then domain, i.e., the usual Windows order)? Please disregard. I forgot the reason was to have the same behavior as the Windows logon screen, which (although different from the API order) is sensible. Regards, Bill -- 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: Zsh and wildcards
On 2019-02-19 13:42, Mike Brown wrote: > Zsh 5.3 under Win7-64 > I'm trying to do the following: > mv TSMUXER/*.ac3 TSMUXER/txmuxer.ac3 > The problem is the the * is not being expanded. I have no idea why not. > Any tips will be appreciated. The command line implies you have a .ac3 file already in TSMUXER and want to rename it to fixed name txmuxer.ac3. A lack of expansion implies there is no file matching that pattern. You can prefix simple commands with echo to test their effect. If a pattern is not expanded, use ls to check what exists in the source directory, and where it differs from your expectation. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. -- 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: ssh confused about home directory?
Am 19.02.2019 um 21:08 schrieb Andrey Repin: Greetings, Boylan, Ross! I recently installed cygwin on Win 10, both 64 bit. When I run ssh in a cygwin shell it complains Could not create directory '/home/rdboylan/.ssh'. The /home directory is empty--that is, it has no rdboylan subdirectory. My home directory appears to be /cygdrive/c/Users/rdboylan; that is the value of $HOME This is the answer. You rely on your shell being smart enough to pick environment variable as operational directive, but SSH knows nothing about it and fails. and where I end up when I do cd. As far as I can tell from the docs, having c:/Users/rdboylan as home is fine, but ssh doesn't seem to be respecting it. /etc/nsswitch.conf has no uncommented lines and /etc/passwd does not exist Which explains the failure. But it does not excuse it. That's background information while the authoritative guide for users should be the manuals. The ssh manual refers to ~, without defining what that exactly means. The bash manual defines ~ to be equivalent with $HOME which also sometimes fails in bash. Documentation and behaviour is inconsistent, probably because in other POSIX systems, there are typically not so many variations in setting up $HOME, or ~, whichever... -- 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
Zsh and wildcards
Zsh 5.3 under Win7-64 I'm trying to do the following: mv TSMUXER/*.ac3 TSMUXER/txmuxer.ac3 The problem is the the * is not being expanded. I have no idea why not. Any tips will be appreciated. MB -- e-mail: vid...@vidiot.com | vid...@vidiot.net/~\ The ASCII 6082066...@email.uscc.net (140 char limit) \ / Ribbon Campaign Visit - URL: http://vidiot.com/ X Against http://vidiot.net/ / \ HTML Email "What do you say Beckett. Wanna have a baby?" - Castle to Det. Beckett "How long have I been gone?" Alexis after seeing Castle and Beckett w/ baby - Castle - 11/25/13 -- 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: Can't create scheduled task over ssh as current user
On Tue, Feb 19, 2019 at 12:28 PM John Oxley wrote: > I started off with PowerShell but re-wrote to schtasks to make this post > shorter. Exactly the same thing happens: > > > Register-ScheduledTask -TaskName $taskName -Action $action -Trigger > > $trigger -RunLevel Highest -User foo -Password $fooPassword > Register-ScheduledTask : The user name or password is incorrect. > At line:1 char:1 > + Register-ScheduledTask -TaskName $taskName -Action $action -Trigger $ ... > + ~ > + CategoryInfo : AuthenticationError: > (PS_ScheduledTask:Root/Microsoft/...S_ScheduledTask) [Register-Schedule >dTask], CimException > + FullyQualifiedErrorId : HRESULT 0x8007052e,Register-ScheduledTask Interesting; I don't know why you're getting error 0x52E (1326 - 'The user name or password is incorrect'). What is the version of the cygwin1.dll you're using? 3.0 now uses Kerberos/MSV1_0 S4U authentication, meaning you can run sshd using the SYSTEM account (recommended). Bill -- 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: ssh confused about home directory?
Greetings, Boylan, Ross! > I recently installed cygwin on Win 10, both 64 bit. > When I run ssh in a cygwin shell it complains > Could not create directory '/home/rdboylan/.ssh'. > The /home directory is empty--that is, it has no rdboylan subdirectory. > My home directory appears to be /cygdrive/c/Users/rdboylan; that is the > value of $HOME This is the answer. You rely on your shell being smart enough to pick environment variable as operational directive, but SSH knows nothing about it and fails. > and where I end up when I do cd. > As far as I can tell from the docs, having c:/Users/rdboylan as home is > fine, but ssh doesn't seem to be respecting it. > /etc/nsswitch.conf has no uncommented lines and /etc/passwd does not exist Which explains the failure. > (both being ways to define the home directory on cygwin according to the > internet). > In a Windows Command Prompt %HOME% is C:\Users\rdboylan > What's the most appropriate way to fix this problem? Configure Cygwin's NSS to your heart's content. Speaking of which, if you move $HOME outside Cygwin root, I would strongly suggest spending some time in fstab, setting up cygdrive to noacl mode. F.e. none /cygdrive cygdrive noacl,binary,nouser,posix=0 0 0 -- With best regards, Andrey Repin Tuesday, February 19, 2019 23:04:19 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
Can't create scheduled task over ssh as current user
Hello all, I'm running a Windows 10 VM with a fairly recent installation of Cygwin (last month or so). If I ssh into the box as the user "foo", I cannot create a scheduled task for the user: foo@host $ schtasks /create /ru foo /rp fooPassword /sc HOURLY /tn foobar /tr 'echo foo' ERROR: The user name or password is incorrect. If on the otherhand I log in as the user "bar" and run exactly the same command, the scheduled task is created bar@host $ schtasks /create /ru foo /rp fooPassword /sc HOURLY /tn foobar4 /tr 'echo foo' SUCCESS: The scheduled task "foobar4" has successfully been created. If I log into the VM with remote desktop as the user foo, I can create the task. I have tried substituting /ru and /rp with /u and /p but get the error ERROR: User credentials are not allowed on the local machine. I am not sure what is going on and would love some help. Thanks -John -- 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: antrun versus wsl versus cygwin
Am 19.02.2019 um 00:36 schrieb Houder: > On Mon, 18 Feb 2019 13:15:02, Franz Fehringer wrote: > >> Am 18.02.2019 um 11:42 schrieb Houder: > [snip] > >>> Now show us the output of an antrun script, where the executable >>> is C:\Tools\Cygwin\bin\which and its argument: bash >> >> >> >> >> >> >> >> >> gives >> >> [exec] /usr/bin/bash >> [exec] W i n d o w s S u b s y s t e m f o r L i n u x h a s n >> o i n s t a l l e d d i s t r i b u ti o n s . >> [exec]D i s t r i b u t i o n s c a n b e i n s t a l l e d >> b y v i s i t i n g t h e M i c r o s o f t S t o r e : >> [exec]h t t p s : / / a k a . m s / w s l s t o r e >> >> It is as if C:\Windows\System32 were hardcoded somewhere >> The ant exec documentation says >> "The task delegates to Runtime.exec which in turn apparently >> calls ::CreateProcess. It is the latter Win32 function that defines the >> exact semantics of the call. " > > Erm, thinking this over ... you may be on the right track ... > > After invoking the Windows executable (JVM or whatever) from Cygwin, "bash" > is started using CreateProcess() > > > https://docs.microsoft.com/en-us/windows/desktop/api/processthreadsapi/nf-processthreadsapi-createprocessa > > Before it searches PATH, CreateProcess checks "the 32-bit Windows system > directory" for the presence of "bash.exe". > > And we know that bash.exe from WSL is present in C:\Windows\System32. That > does explain why the output of bash from WSL is shown, does it not? > (reporting that a distribution is still to be installed). > > The above also explains why renaming bash from WSL to "wslbash.exe" forces > CreateProcess() to search for the presence of bash.exe down the PATH. > > Henri > > Yes, that is it most probably (and unfortunately). -- 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: Can't create scheduled task over ssh as current user
On Tue, Feb 19, 2019 at 12:02 PM John Oxley wrote: > I'm running a Windows 10 VM with a fairly recent installation of Cygwin (last > month or so). > > If I ssh into the box as the user "foo", I cannot create a scheduled task for > the user: > > foo@host $ schtasks /create /ru foo /rp fooPassword /sc HOURLY /tn foobar /tr > 'echo foo' > ERROR: The user name or password is incorrect. > > If on the otherhand I log in as the user "bar" and run exactly the same > command, the scheduled task is created > > bar@host $ schtasks /create /ru foo /rp fooPassword /sc HOURLY /tn foobar4 > /tr 'echo foo' > SUCCESS: The scheduled task "foobar4" has successfully been created. > > If I log into the VM with remote desktop as the user foo, I can create the > task. > > I have tried substituting /ru and /rp with /u and /p but get the error > ERROR: User credentials are not allowed on the local machine. > > I am not sure what is going on and would love some help. Regarding schtasks: The /u and /p parameters mean "credentials for the user that has permission to create a task," not "credentials for the task itself" (credentials for the task itself are /ru and /rp). They only work for a remote machine (/s parameter). With that said: Why do you need to ssh to the machine to create a task? Just create the task remotely from the machine you're on. I'd recommend PowerShell anyway for more flexibility (New-ScheduledTask, etc.). Bill -- 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
ssh confused about home directory?
I recently installed cygwin on Win 10, both 64 bit. When I run ssh in a cygwin shell it complains Could not create directory '/home/rdboylan/.ssh'. The /home directory is empty--that is, it has no rdboylan subdirectory. My home directory appears to be /cygdrive/c/Users/rdboylan; that is the value of $HOME and where I end up when I do cd. As far as I can tell from the docs, having c:/Users/rdboylan as home is fine, but ssh doesn't seem to be respecting it. /etc/nsswitch.conf has no uncommented lines and /etc/passwd does not exist (both being ways to define the home directory on cygwin according to the internet). In a Windows Command Prompt %HOME% is C:\Users\rdboylan What's the most appropriate way to fix this problem? Thanks. Ross -- 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: ssh confused about home directory?
[Answering my own question after better searching] Same question asked and answered in the thread starting https://cygwin.com/ml/cygwin/2016-06/msg00400.html. The answer is to set db_home in nsswitch.conf. Comment: the current behavior strikes me as unfortunate and surprising. From: Boylan, Ross Sent: Tuesday, February 19, 2019 11:15:47 AM To: cygwin@cygwin.com Subject: ssh confused about home directory? I recently installed cygwin on Win 10, both 64 bit. When I run ssh in a cygwin shell it complains Could not create directory '/home/rdboylan/.ssh'. The /home directory is empty--that is, it has no rdboylan subdirectory. My home directory appears to be /cygdrive/c/Users/rdboylan; that is the value of $HOME and where I end up when I do cd. As far as I can tell from the docs, having c:/Users/rdboylan as home is fine, but ssh doesn't seem to be respecting it. /etc/nsswitch.conf has no uncommented lines and /etc/passwd does not exist (both being ways to define the home directory on cygwin according to the internet). In a Windows Command Prompt %HOME% is C:\Users\rdboylan What's the most appropriate way to fix this problem? Thanks. Ross -- 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: Can't create scheduled task over ssh as current user
From: cygwin-ow...@cygwin.com on behalf of Bill Stewart Sent: 19 February 2019 19:15 To: cygwin@cygwin.com Subject: Re: Can't create scheduled task over ssh as current user On Tue, Feb 19, 2019 at 12:02 PM John Oxley wrote: >> I'm running a Windows 10 VM with a fairly recent installation of Cygwin >> (last month or so). >> If I ssh into the box as the user "foo", I cannot create a scheduled task >> for the user: >> foo@host $ schtasks /create /ru foo /rp fooPassword /sc HOURLY /tn foobar >> /tr 'echo foo' >> ERROR: The user name or password is incorrect. > Regarding schtasks: > The /u and /p parameters mean "credentials for the user that has > permission to create a task," not "credentials for the task itself" > (credentials for the task itself are /ru and /rp). They only work for > a remote machine (/s parameter). Yeah, I figured that out. I was trying to use "/s hostname /u foo /p fooPassword" to try and force a remote setup. > With that said: Why do you need to ssh to the machine to create a > task? Just create the task remotely from the machine you're on. In this case I am on a Linux machine. I have a lot of automation setup from Linux boxes to manage the Windows VMs. > I'd recommend PowerShell anyway for more flexibility (New-ScheduledTask, > etc.). I started off with PowerShell but re-wrote to schtasks to make this post shorter. Exactly the same thing happens: > Register-ScheduledTask -TaskName $taskName -Action $action -Trigger $trigger > -RunLevel Highest -User foo -Password $fooPassword Register-ScheduledTask : The user name or password is incorrect. At line:1 char:1 + Register-ScheduledTask -TaskName $taskName -Action $action -Trigger $ ... + ~ + CategoryInfo : AuthenticationError: (PS_ScheduledTask:Root/Microsoft/...S_ScheduledTask) [Register-Schedule dTask], CimException + FullyQualifiedErrorId : HRESULT 0x8007052e,Register-ScheduledTask -- 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: Windows to Cygwin username mapping: Domain before local account when duplicate name?
Greetings, Bill Stewart! > On Fri, Feb 15, 2019 at 3:48 PM Bill Stewart wrote: >> This means that when I test getent using the name "Admin", Cygwin >> finds the domain group: >> >> PS C:\> getent -w passwd admin >> admin::DOMAINNAME\admin:S-1-5-21-nn-n-n-nn >> >> I get that this is by design, but .NET finds the local account first, >> which is what I was expecting: >> >> PS C:\> $name = [Security.Principal.NTAccount] "admin" >> PS C:\> $sid = $name.Translate([Security.Principal.SecurityIdentifier]) >> PS C:\> $sid.Translate([Security.Principal.NTAccount]) >> >> Value >> - >> COMPUTERNAME\Admin > So then - just to follow up - Cygwin is for sure going to stick with > "domain first" when resolving an account name that doesn't include an > authority. No. > (a) Is this correct? No. > (b) Is there a particular reason this order was chosen (instead of > local first, then domain, i.e., the usual Windows order)? No. -- With best regards, Andrey Repin Tuesday, February 19, 2019 20:11:34 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: [PATCH] Cygwin: add secure_getenv
On Feb 18 23:09, Yaakov Selkowitz wrote:
> Signed-off-by: Yaakov Selkowitz
> ---
> This is being used more frequently. Since we don't have Linux capabilities,
> setuid/setgid is the only condition we have to check.
I'm not sure this is right. The Linux man page claims
"Secure execution is required if one of the following conditions was
true when the program run by the calling process was loaded: [...]"
Do we ever have this situation? We don't have any capability to make
real and effective user ID different at process startup. But from that
description it seems secure_getenv does not trigger secure mode if the
process calls seteuid() or setreuid() later in the process.
I ran this STC as root under Linux:
# cat > sec-getenv-test.c <
#include
#include
#include
#include
#include
int main ()
{
char *env;
env = secure_getenv ("HOME");
printf ("vor seteuid: HOME=%p <%s>\n", env, env ?: "");
if (seteuid (74) < 0)
printf ("seteuid: %d <%s>\n", errno, strerror (errno));
else
{
env = secure_getenv ("HOME");
printf ("nach seteuid: HOME=%p <%s>\n", env, env ?: "");
}
return 0;
}
EOF
# gcc -g -o sec-getenv-test sec-getenv-test.c
# ./sec-getenv-test
vor seteuid: HOME=0x7fff17a04ea2
nach seteuid: HOME=0x7fff17a04ea2
Corinna
--
Corinna Vinschen
Cygwin Maintainer
signature.asc
Description: PGP signature
Re: [PATCH] Cygwin: add secure_getenv
On Feb 19 12:43, Corinna Vinschen wrote:
> On Feb 18 23:09, Yaakov Selkowitz wrote:
> > Signed-off-by: Yaakov Selkowitz
> > ---
> > This is being used more frequently. Since we don't have Linux capabilities,
> > setuid/setgid is the only condition we have to check.
>
> I'm not sure this is right. The Linux man page claims
>
> "Secure execution is required if one of the following conditions was
> true when the program run by the calling process was loaded: [...]"
>
> Do we ever have this situation? We don't have any capability to make
> real and effective user ID different at process startup. But from that
> description it seems secure_getenv does not trigger secure mode if the
> process calls seteuid() or setreuid() later in the process.
>
> I ran this STC as root under Linux:
>
> # cat > sec-getenv-test.c < #define _GNU_SOURCE
> #include
> #include
> #include
> #include
> #include
> #include
>
> int main ()
> {
> char *env;
>
> env = secure_getenv ("HOME");
> printf ("vor seteuid: HOME=%p <%s>\n", env, env ?: "");
> if (seteuid (74) < 0)
> printf ("seteuid: %d <%s>\n", errno, strerror (errno));
> else
> {
> env = secure_getenv ("HOME");
> printf ("nach seteuid: HOME=%p <%s>\n", env, env ?: "");
> }
> return 0;
> }
> EOF
> # gcc -g -o sec-getenv-test sec-getenv-test.c
> # ./sec-getenv-test
> vor seteuid: HOME=0x7fff17a04ea2
> nach seteuid: HOME=0x7fff17a04ea2
I also tried to run secure_getenv after fork, like this:
seteuid()
if (fork () == 0)
env = secure_getenv ("HOME");
but it still returns a valid value.
So I wonder if secure_getenv isn't just a synonym for getenv
in our case.
Corinna
--
Corinna Vinschen
Cygwin Maintainer
signature.asc
Description: PGP signature
Re: [PATCH] Cygwin: add secure_getenv
On Tue, 2019-02-19 at 12:59 +0100, Corinna Vinschen wrote:
> On Feb 19 12:43, Corinna Vinschen wrote:
> > On Feb 18 23:09, Yaakov Selkowitz wrote:
> > > Signed-off-by: Yaakov Selkowitz
> > > ---
> > > This is being used more frequently. Since we don't have Linux
> > > capabilities,
> > > setuid/setgid is the only condition we have to check.
> >
> > I'm not sure this is right. The Linux man page claims
> >
> > "Secure execution is required if one of the following conditions was
> > true when the program run by the calling process was loaded: [...]"
> >
> > Do we ever have this situation? We don't have any capability to make
> > real and effective user ID different at process startup. But from that
> > description it seems secure_getenv does not trigger secure mode if the
> > process calls seteuid() or setreuid() later in the process.
> >
> > I ran this STC as root under Linux:
> >
> > # cat > sec-getenv-test.c < > #define _GNU_SOURCE
> > #include
> > #include
> > #include
> > #include
> > #include
> > #include
> >
> > int main ()
> > {
> > char *env;
> >
> > env = secure_getenv ("HOME");
> > printf ("vor seteuid: HOME=%p <%s>\n", env, env ?: "");
> > if (seteuid (74) < 0)
> > printf ("seteuid: %d <%s>\n", errno, strerror (errno));
> > else
> > {
> > env = secure_getenv ("HOME");
> > printf ("nach seteuid: HOME=%p <%s>\n", env, env ?: "");
> > }
> > return 0;
> > }
> > EOF
> > # gcc -g -o sec-getenv-test sec-getenv-test.c
> > # ./sec-getenv-test
> > vor seteuid: HOME=0x7fff17a04ea2
> > nach seteuid: HOME=0x7fff17a04ea2
>
> I also tried to run secure_getenv after fork, like this:
>
> seteuid()
> if (fork () == 0)
> env = secure_getenv ("HOME");
>
> but it still returns a valid value.
>
> So I wonder if secure_getenv isn't just a synonym for getenv
> in our case.
Or could it be the STC? glibc's test is a bit more complicated:
https://sourceware.org/git/?p=glibc.git;a=blob;f=stdlib/tst-secure-getenv.c;hb=HEAD
And, looking now, FWIW gnulib's implementation is practically similar:
https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/secure_getenv.c;hb=HEAD
So if there is something wrong with the patch, then AFAIK gnulib is
wrong too. Eric?
--
Yaakov Selkowitz
Senior Software Engineer - Platform Enablement
Red Hat, Inc.
Re: [Adopt] Iperf package [2.0.13].
I've been away from email access the past bit and am just getting back. I originally refrained from updating the package to the iperf2 fork since at the time it wasn't clearly endorsed. Now that the original project recommends it as an alternative to iperf3 I don't have any objection to it being updated. Joel On 2019-02-01 09:05, Marco Atzeri wrote: Am 29.01.2019 um 04:13 schrieb Kaushik Battu: Iperf package has not been updated from long time ago, it looks to be in orphaned stage. I would like to maintain the iperf package and upgrade it to version-2.0.13 . Here are the enhancements of iperf 2.0.13 : https://sourceforge.net/projects/iperf2/ Regards, Kaushik Battu. Kaushik, for an ITA (Intention to Adpot) you should provide a working copy for both arch of the packages for evaluation. This of course assuming that Joel Johnson is not anymore interested to be the maintainer. Joel please let us know Regards Marco --- Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft. https://www.avast.com/antivirus
Re: [Adopt] Iperf package [2.0.13].
Thanks Joel. I have tried to upload 2.0.13 package. $ cygport iperf.cygport up >>> Uploading iperf-2.0.13-1.i686 >>> Running lftp sftp://cyg...@cygwin.com Password: cd ok, cwd=/x86/release Transferring file `iperf-2.0.13-1-src.tar.xz' Transferring file `iperf-2.0.13-1.hint' Transferring file `iperf-2.0.13-1.tar.xz' Making directory `iperf-debuginfo' Transferring file `iperf-debuginfo/iperf-debuginfo-2.0.13-1.hint' Transferring file `iperf-debuginfo/iperf-debuginfo-2.0.13-1.tar.xz' Total: 1 directory, 5 files, 0 symlinks New: 5 files, 0 symlinks 605745 bytes transferred in 5 seconds (110.3 KiB/s) Upload complete. Iperf3 is limited in features (as it is single threaded). For testing throughput/Latency on wlan interfaces still people prefer to use iperf2. - Battu. On Wed, 20 Feb 2019 at 09:01, Joel Johnson wrote: > I've been away from email access the past bit and am just getting back. > I originally refrained from updating the package to the iperf2 fork > since at the time it wasn't clearly endorsed. Now that the original > project recommends it as an alternative to iperf3 I don't have any > objection to it being updated. > > Joel > > On 2019-02-01 09:05, Marco Atzeri wrote: > > Am 29.01.2019 um 04:13 schrieb Kaushik Battu: > >> Iperf package has not been updated from long time ago, it looks to be > >> in > >> orphaned stage. I would like to maintain the iperf package and upgrade > >> it > >> to version-2.0.13 . > >> > >> Here are the enhancements of iperf 2.0.13 : > >> https://sourceforge.net/projects/iperf2/ > >> > >> Regards, > >> Kaushik Battu. > >> > > > > Kaushik, > > for an ITA (Intention to Adpot) you should > > provide a working copy for both arch of > > the packages for evaluation. > > > > This of course assuming that Joel Johnson is not anymore > > interested to be the maintainer. > > Joel please let us know > > > > Regards > > Marco > > > > > > > > --- > > Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft. > > https://www.avast.com/antivirus >
[newlib-cygwin] Cygwin: document secure_getenv
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=a62b29bfec6d8c6cf3f285b4c7a5edcf4abf33e1 commit a62b29bfec6d8c6cf3f285b4c7a5edcf4abf33e1 Author: Yaakov Selkowitz Date: Tue Feb 19 14:34:18 2019 -0600 Cygwin: document secure_getenv Signed-off-by: Yaakov Selkowitz Diff: --- winsup/cygwin/release/3.0.1 | 2 ++ winsup/doc/new-features.xml | 6 +++--- 2 files changed, 5 insertions(+), 3 deletions(-) diff --git a/winsup/cygwin/release/3.0.1 b/winsup/cygwin/release/3.0.1 index 1894c5c..467bf23 100644 --- a/winsup/cygwin/release/3.0.1 +++ b/winsup/cygwin/release/3.0.1 @@ -1,6 +1,8 @@ What's new: --- +- New API: secure_getenv. + What changed: - diff --git a/winsup/doc/new-features.xml b/winsup/doc/new-features.xml index 8fc0ac6..ab369ab 100644 --- a/winsup/doc/new-features.xml +++ b/winsup/doc/new-features.xml @@ -43,7 +43,7 @@ Support Linux-specific open(2) flag O_PATH. -- Support Linux-specific linkat(2) flag AT_EMPTY_PATH. +Support Linux-specific linkat(2) flag AT_EMPTY_PATH. @@ -52,8 +52,8 @@ siginfo_t::si_overrun). -New APIs: signalfd, timerfd_create, timerfd_gettime, timerfd_settime, -timer_getoverrun. +New APIs: secure_getenv, signalfd, timerfd_create, timerfd_gettime, +timerfd_settime, timer_getoverrun.
Re: [PATCH] Cygwin: add secure_getenv
On Feb 19 11:27, Eric Blake wrote: > On 2/19/19 11:21 AM, Corinna Vinschen wrote: > > >> That said, while it is ideal to avoid squashing to NULL in situations > >> that are not security boundaries (as with your STC displaying HOME even > >> after seteuid() on Linux), I'm also okay if we filter too aggressively > >> (the way gnulib's fallback implementation does when neither > >> __secure_getenv() nor issetugid() available). > > > > In fact, gnulib's implementation would chose the > > > >if (issetugid ()) > > return NULL; > >return getenv (name); > > > > branch on Cygwin right now, just as on BSDs. If that's the right thing > > to do for BSD, it's not... *really* wrong for Cygwin either, regardless > > what Linux is doing. > > > > That in turn means Yaakov's patch is perfeclty fine since it's equivalent > > to the above gnulib code. > > > > Agreed? > > Yes. Fine, thanks. Patch is ok to push, Yaakov, just add release msg changes, too. Thanks, Corinna -- Corinna Vinschen Cygwin Maintainer signature.asc Description: PGP signature
[newlib-cygwin] Cygwin: add secure_getenv
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=850705f92e3371bc0c56cee270327add84cd441a
commit 850705f92e3371bc0c56cee270327add84cd441a
Author: Yaakov Selkowitz
Date: Mon Feb 18 23:06:11 2019 -0600
Cygwin: add secure_getenv
Signed-off-by: Yaakov Selkowitz
Diff:
---
newlib/libc/include/stdlib.h | 3 +++
winsup/cygwin/common.din | 1 +
winsup/cygwin/environ.cc | 10 ++
winsup/cygwin/include/cygwin/version.h | 3 ++-
winsup/doc/posix.xml | 1 +
5 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/newlib/libc/include/stdlib.h b/newlib/libc/include/stdlib.h
index 9773d36..933d181 100644
--- a/newlib/libc/include/stdlib.h
+++ b/newlib/libc/include/stdlib.h
@@ -94,6 +94,9 @@ void exit (int __status) _ATTRIBUTE ((__noreturn__));
void free (void *) _NOTHROW;
char * getenv (const char *__string);
char * _getenv_r (struct _reent *, const char *__string);
+#if __GNU_VISIBLE
+char * secure_getenv (const char *__string);
+#endif
char * _findenv (const char *, int *);
char * _findenv_r (struct _reent *, const char *, int *);
#if __POSIX_VISIBLE >= 200809
diff --git a/winsup/cygwin/common.din b/winsup/cygwin/common.din
index f620d81..68b95d4 100644
--- a/winsup/cygwin/common.din
+++ b/winsup/cygwin/common.din
@@ -1255,6 +1255,7 @@ sched_rr_get_interval SIGFE
sched_setparam SIGFE
sched_setscheduler SIGFE
sched_yield SIGFE
+secure_getenv NOSIGFE
seed48 NOSIGFE
seekdir SIGFE
select = cygwin_select SIGFE
diff --git a/winsup/cygwin/environ.cc b/winsup/cygwin/environ.cc
index 495c340..21f1373 100644
--- a/winsup/cygwin/environ.cc
+++ b/winsup/cygwin/environ.cc
@@ -549,6 +549,16 @@ _getenv_r (struct _reent *, const char *name)
return findenv_func (name, );
}
+/* Like getenv, but returns NULL if effective and real UID/GIDs do not match */
+extern "C" char *
+secure_getenv (const char *name)
+{
+ int offset;
+ if (cygheap->user.issetuid ())
+return NULL;
+ return findenv_func (name, );
+}
+
/* Return number of environment entries, including terminating NULL. */
static int __stdcall
envsize (const char * const *in_envp)
diff --git a/winsup/cygwin/include/cygwin/version.h
b/winsup/cygwin/include/cygwin/version.h
index 2c55f4b..d865f29 100644
--- a/winsup/cygwin/include/cygwin/version.h
+++ b/winsup/cygwin/include/cygwin/version.h
@@ -508,12 +508,13 @@ details. */
335: Change size of utsname, change uname output.
336: New Cygwin PID algorithm (yeah, not really an API change)
337: MOUNT_BINARY -> MOUNT_TEXT
+ 338: Export secure_getenv.
Note that we forgot to bump the api for ualarm, strtoll, strtoull,
sigaltstack, sethostname. */
#define CYGWIN_VERSION_API_MAJOR 0
-#define CYGWIN_VERSION_API_MINOR 337
+#define CYGWIN_VERSION_API_MINOR 338
/* There is also a compatibity version number associated with the shared memory
regions. It is incremented when incompatible changes are made to the shared
diff --git a/winsup/doc/posix.xml b/winsup/doc/posix.xml
index 8e9b1a5..0755bed 100644
--- a/winsup/doc/posix.xml
+++ b/winsup/doc/posix.xml
@@ -1377,6 +1377,7 @@ also IEEE Std 1003.1-2008 (POSIX.1-2008).
removexattr
scandirat
sched_getcpu
+secure_getenv
setxattr
signalfd
sincos
Re: [PATCH] Cygwin: add secure_getenv
On 2/19/19 10:58 AM, Yaakov Selkowitz wrote: >>> "Secure execution is required if one of the following conditions was >>> true when the program run by the calling process was loaded: [...]" >>> >>> Do we ever have this situation? We don't have any capability to make >>> real and effective user ID different at process startup. But from that >>> description it seems secure_getenv does not trigger secure mode if the >>> process calls seteuid() or setreuid() later in the process. It says it may also be triggered by some Linux security modules (for which I'll assume that can include states that were not present at startup). The main reason it was invented was to ensure that a setgid application CANNOT be negatively impacted by LD_PRELOAD and friends prior to main(), because all of the startup code in the dynamic loader was switched to use secure_getenv() for any place where the loader can normally be influenced by the environment. But the wording sounds vague enough about what other situations may be considered as security that it is easy enough to just state that you should always be prepared for a NULL return when using the function. That said, while it is ideal to avoid squashing to NULL in situations that are not security boundaries (as with your STC displaying HOME even after seteuid() on Linux), I'm also okay if we filter too aggressively (the way gnulib's fallback implementation does when neither __secure_getenv() nor issetugid() available). >> So I wonder if secure_getenv isn't just a synonym for getenv >> in our case. > > Or could it be the STC? glibc's test is a bit more complicated: > > https://sourceware.org/git/?p=glibc.git;a=blob;f=stdlib/tst-secure-getenv.c;hb=HEAD > > And, looking now, FWIW gnulib's implementation is practically similar: > > https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/secure_getenv.c;hb=HEAD Gnulib argued that for native windows, being a synonym for getenv() is okay because you have to opt in to running as administrator, and that there is no native setuid/setgid binaries where you can otherwise gain privileges by influencing the environment presented to a binary. Of course, if Cygwin is able to emulate setgid binaries where native Windows can't, then we need secure_getenv() to reflect that emulation. > > So if there is something wrong with the patch, then AFAIK gnulib is > wrong too. Eric? The patch may be overly strict (returning NULL where it doesn't have to), but that does not make it wrong in my eyes. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
Re: [PATCH] Cygwin: add secure_getenv
On 2/19/19 11:21 AM, Corinna Vinschen wrote: >> That said, while it is ideal to avoid squashing to NULL in situations >> that are not security boundaries (as with your STC displaying HOME even >> after seteuid() on Linux), I'm also okay if we filter too aggressively >> (the way gnulib's fallback implementation does when neither >> __secure_getenv() nor issetugid() available). > > In fact, gnulib's implementation would chose the > >if (issetugid ()) > return NULL; >return getenv (name); > > branch on Cygwin right now, just as on BSDs. If that's the right thing > to do for BSD, it's not... *really* wrong for Cygwin either, regardless > what Linux is doing. > > That in turn means Yaakov's patch is perfeclty fine since it's equivalent > to the above gnulib code. > > Agreed? Yes. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
[newlib-cygwin] Cygwin: sys/mount.h: fix comment
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=dd415f1a8c0480303a38f8f4612430c201e967cc
commit dd415f1a8c0480303a38f8f4612430c201e967cc
Author: Corinna Vinschen
Date: Tue Feb 19 19:34:40 2019 +0100
Cygwin: sys/mount.h: fix comment
Signed-off-by: Corinna Vinschen
Diff:
---
winsup/cygwin/include/sys/mount.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/winsup/cygwin/include/sys/mount.h
b/winsup/cygwin/include/sys/mount.h
index 0c4e078..8221d1a 100644
--- a/winsup/cygwin/include/sys/mount.h
+++ b/winsup/cygwin/include/sys/mount.h
@@ -22,7 +22,7 @@ extern "C" {
enum
{
- MOUNT_TEXT = _BIT ( 0), /* "binary" format read/writes */
+ MOUNT_TEXT = _BIT ( 0), /* "text" format read/writes */
MOUNT_SYSTEM = _BIT ( 3), /* mount point came from system table */
MOUNT_EXEC = _BIT ( 4), /* Any file in the mounted directory
gets 'x' bit */
Re: [PATCH] Cygwin: add secure_getenv
On Feb 19 11:14, Eric Blake wrote: > On 2/19/19 10:58 AM, Yaakov Selkowitz wrote: > > >>> "Secure execution is required if one of the following conditions was > >>> true when the program run by the calling process was loaded: [...]" > >>> > >>> Do we ever have this situation? We don't have any capability to make > >>> real and effective user ID different at process startup. But from that > >>> description it seems secure_getenv does not trigger secure mode if the > >>> process calls seteuid() or setreuid() later in the process. > > It says it may also be triggered by some Linux security modules (for > which I'll assume that can include states that were not present at > startup). The main reason it was invented was to ensure that a setgid > application CANNOT be negatively impacted by LD_PRELOAD and friends > prior to main(), because all of the startup code in the dynamic loader > was switched to use secure_getenv() for any place where the loader can > normally be influenced by the environment. But the wording sounds vague > enough about what other situations may be considered as security that it > is easy enough to just state that you should always be prepared for a > NULL return when using the function. > > That said, while it is ideal to avoid squashing to NULL in situations > that are not security boundaries (as with your STC displaying HOME even > after seteuid() on Linux), I'm also okay if we filter too aggressively > (the way gnulib's fallback implementation does when neither > __secure_getenv() nor issetugid() available). In fact, gnulib's implementation would chose the if (issetugid ()) return NULL; return getenv (name); branch on Cygwin right now, just as on BSDs. If that's the right thing to do for BSD, it's not... *really* wrong for Cygwin either, regardless what Linux is doing. That in turn means Yaakov's patch is perfeclty fine since it's equivalent to the above gnulib code. Agreed? Corinna -- Corinna Vinschen Cygwin Maintainer signature.asc Description: PGP signature
