Re: Non-privileged use can't logon

["max dot rockliff at bigpond dot com" <max dot rockliff at bigpond dot com>]

Aha! So what you're saying is that in all likelihood the old version I was running didn't have this problem because it simply didn't try to use the windows environment hence no reference to userenv. However some time in the past couple of years this functionality was introduced and I get the error.. Could be a backwards compatibility issue as I'm running it on vista whereas Georg said yesterday that he'd upgraded Cygwin on Win8 and didn't experience the same problem with non-privileged accounts.  Interesting but! I'm working and for that I am grateful :)

I heard you say this type of error had been a problem on and off but with other dlls. Maybe there's a fundamental compatibility issue or maybe a calling convention in the APIs or function definitions from time to time in different Windows versions. .....Just maybe. 

Max

> On 11 Mar 2015, at 8:50 pm, Corinna Vinschen <corinna-cygwin@cygwin.com> wrote:
> 
> Please, https://cygwin.com/acronyms/#TOFU
> 
> Thank you.
> 
> On Mar 11 20:40, Max Rockliff wrote:
>>>> Any ideas?
>>> 
>>> Depends.  As for the actual cause why userenv.dll refuses to load, no.
>>> It's just a simple LoadLibrary call, nothing fancy.  I just tried the
>>> same scenario on my local 8.1 test machine and logging in with an
>>> unprivileged account worked fine.
>>> 
>>> I tried to come up with a workaround for the problem, though.  I just
>>> uploaded a new developer snapshot to https://cygwin.com/snapshots/
>>> 
>>> Just fetch the latest 32 bit cygwin1.dll,
>>> http://cygwin.com/snapshots/x86/cygwin1-20150311.dll.xz
>>> 
>>> Unxz it, chmod +x it.  Stop all Cygwin processes.  In Windows
>>> Explorer, open the C:\cygwin\bin directory.  Rename the original
>>> cygwin1.dll to cygwin1.dll.ORIG.  Move the new cygwin1-20150311.dll
>>> into place and rename it to cygwin1.dll.  Retry your scenario.  And
>>> please report back.
>> 
>> Hey Corinna,
>> 
>> You're a magician.  It seems to have fixed the problem, or at least provided an effective workaround.  Here's a transcript (kinda)
>> 
>> 1.  Downloaded the new cygwin1-20150311.dll.xz  (PS. Kudos for using a
>> yyyymmdd format in the name - I always do, but so many don't
>> 2.  Copied the xz file to my privileged user account home folder and
>> Unxz'ed it.
>> 3.  Used Windows to copy the file cygwin1-20150311.dll to the
>> C:\cygwin\bin folder
>> 4.  Stopped the SSHD service
>> 5.  Renamed the old cygwin1.dll to cygwin1.dll.old
>> 6.  Renamed cygwin1-20150311.dll to cygwin1.dll
>> 7.  Started the SSHD service
>> 8.  Started the terminal
>> 9.  Executed ssh st@localhost and it logged on successfully no errors.
>>    Max@Max-PC /bin
>>    $ ssh st@localhost
>>    st@localhost's password:
>>    Last login: Wed Mar 11 20:32:00 2015 from ::1
>> 
>>    st@Max-PC ~
>>    $
>> 10.  And, as we like to say in Australia - Sweet!
>> 
>> What on earth did you change that made the error go away?
> 
> You don't want to know.
> .
> [spoiler alert]
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> I made loading userenv.dll non-fatal in this specific case.  The result
> is that, in scenarios like yours, the user's Windows environment won't
> be merged into the environment of the user's shell started from sshd.
> However, since that's a new functionality anyway, you're not worse off
> than with earlier Cygwin versions.
> 
> 
> Corinna
> 
> -- 
> Corinna Vinschen                  Please, send mails regarding Cygwin to
> Cygwin Maintainer                 cygwin AT cygwin DOT com
> Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple