date:20120816

On Thu, Aug 16, 2012 at 04:41:39PM -0400, Lord Laraby wrote:
>Could someone please delete that first copy of this message. Somehow,
>it got through with a non-ubfuscated email address. I'm sorry.

It doesn't work like that.  No one wants a full time job cleaning up
after other people's email gaffes.

--
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: Promote sqlite 3.7.13-1 from test status?

2012-08-16 Thread JonY

On 8/17/2012 02:22, Warren Young wrote:
> On 8/16/2012 10:34 AM, Brian Wilson wrote:
>>
>> Corina
> 
> Corinna.
> 
>> is correct, Cygwin is supposed to be a Posix compliant environment
> 
> It's also supposed to interoperate with native Windows programs.
> 

That's fine when it works, but that is not always the case.

>> If you want to use Windoze tools, why are you using Cygwin?
> 
> First, instant 100 point credibility penalty for being puerile.
> 
> Second, the whole reason for using Cygwin is so you could have a
> Linux/POSIX environment *on Windows.*  If you have no need for Windows
> programs and want a Cygwin-like environment, wouldn't you be running
> Linux, or a BSD, or OS X, or Solaris, or...?
> 

So it's Cygwin's fault when a Windows program interferes with it? I
still think Cygwin should prioritize compatibility with Cygwin programs,
anything else is just icing on the cake.

> Okay, so you come back saying something about how there should be some
> Chinese Wall between the Cygwin and native Windows lands.  In that case,
> I recommend you install one of the above-named OSes in a VM.  It'll be
> faster and more featureful.
> 

In fact, yes, especially in places win32 clashes with POSIX
implementation. I could go on and on about how they differ, for example
BLODA, network API, file IO, symlink implementation, you've just seen
one yourself.

> I'm actually struggling to come up with a reason why you would *ever*
> run Cygwin if you didn't ever want it to touch the native Windows side
> of things, or vice versa.  I guess it uses less RAM and starts up faster
> than a VM

Sure, a VM isn't always practical or even available, especially when
byzantine IT policies is in place. For instance, I don't want a VM
simply to use a Cygwin irc client.

signature.asc
Description: OpenPGP digital signature

Re: Question about UAC and bash/cygwin

2012-08-16 Thread Linda Walsh

Lord Laraby wrote:

I'll give that a go as a start. But, I would still like to see by
Cygwin uid shown as 0 when I am elevated. Because it's the same as the
windows equivalent of su.

---
I think where you are confused is that cygwin's shell is
elevated all the time if you are running as admin...

It's *almost* like the good ole days when you owned your machine
and you were the only one on it. but not quite..

cygwin can't directly access 64-bit resources and is therefor subject
to path redirection.

But if you put the 'right' values in your groups file:
when you type id you will see not only your groups, but your tokens as well (if
you've

populated your group file).

id
uid=1001(lindaw) gid=544(Administrators)
groups=544(Administrators),11(Authenticated
Users),513(None),545(Users),555(Remote Desktop Users),1005(lawgroup),12288(High
Mandatory Level)

So ... from the above, I am in group "root" (which is called Administrators and
has a value

of 544 on windows) I'm in the authenticated users group (I'm logged in).
513 is for Domain Users, but for a standalone machine... cygwin defaults it to
none.

and the HighMandatory is my integrity...

Values for those in /etc/group would be:

High Mandatory Level:S-1-16-12288:12288:
System Mandatory Level:S-1-16-16384:16384:
Protected Mandatory Level:S-1-16-20480:20480:
Secure Mandatory Level:S-1-16-28672:28672:

I also have this for Trusted Installer, but it may be specific to my system:

TrustedInstaller:S-1-5-80-3139157870-2983391045-3678747466-658725712-1809340420:1809340420

If you want to see yourself in group root, you can add this
to your /etc/group file:
root:S-1-5-32-544:0:
^^^--- notice the 544 -- that's the number windows uses

you should have an entry in your group file like:

Administrators:S-1-5-32-544:544:
^ that's the real Admin/root group, and it
normally is mapped to

the number windows uses.

Some other group entries that might come in handy:

SERVICE:S-1-5-6:6:
Authenticated Users:S-1-5-11:11:
SYSTEM:S-1-5-18:18:
Local Service:S-1-5-19:19:
Network Service:S-1-5-20:20:
Administrators:S-1-5-32-544:544:
Users:S-1-5-32-545:545:
Guests:S-1-5-32-546:546:
Power Users:S-1-5-32-547:547:
Remote Desktop Users:S-1-5-32-555:555:

Does that help clarify anything Lord?

--
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: Promote sqlite 3.7.13-1 from test status?

2012-08-16 Thread James Johnston

> -Original Message-
> Sent: Thursday, August 16, 2012 18:22
> To: Cygwin-L
> Subject: Re: Promote sqlite 3.7.13-1 from test status?
> 
> On 8/16/2012 10:34 AM, Brian Wilson wrote:
> > is correct, Cygwin is supposed to be a Posix compliant environment
> 
> It's also supposed to interoperate with native Windows programs.
> 
> > If you want to use Windoze tools, why are you using Cygwin?
> 
> First, instant 100 point credibility penalty for being puerile.
> 
> Second, the whole reason for using Cygwin is so you could have a
> Linux/POSIX environment *on Windows.*  If you have no need for Windows
> programs and want a Cygwin-like environment, wouldn't you be running
> Linux, or a BSD, or OS X, or Solaris, or...?
> 
> Okay, so you come back saying something about how there should be some
> Chinese Wall between the Cygwin and native Windows lands.  In that case, I
> recommend you install one of the above-named OSes in a VM.  It'll be
faster
> and more featureful.
> 
> I'm actually struggling to come up with a reason why you would *ever* run
> Cygwin if you didn't ever want it to touch the native Windows side of
things,
> or vice versa.  I guess it uses less RAM and starts up faster than a
VM

I was just about to start writing a similar message to this, but you did it
for me very perfectly!  What's the point of Cygwin if it can't play nice
with other Windows programs on the system?  Go run Linux then!  I can point
out several well-known distributions that would work fine.  The best part is
they don't require paying license fees to an operating system vendor.

Sometimes I don't understand the antagonism towards interop with native
Windows programs that don't do anything unusual and do things by the
(Windows) book.  It seems like it defeats the point of the project if that
goes too far.  What's wrong with being pragmatic sometimes? 

--
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: Question about UAC and bash/cygwin

Could someone please delete that first copy of this message. Somehow,
it got through with a non-ubfuscated email address. I'm sorry.

LL

--
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: Question about UAC and bash/cygwin

On Thu, Aug 16, 2012 Christian Franke wrote:
> Corinna Vinschen wrote:
>>
>> On Aug 16 07:06, Lord Laraby wrote:
>-8
>>
>> What is it good for to have uid 0?  You want to know if you have admin
>> rights, so why don't you simply check for the admin group in the
>> supplementary group list?
>>
>> Here's what I do in my tcsh ~/.cshrc profile to set the prompt:
>>
>>id -G | egrep -q '\<544\>' && set prompt = '#  || set prompt = '\$ '
>>
>>
>
> I use this simple check which does not depend on /etc/group contents:
>
>  test -r /proc/registry/HKEY_LOCAL_MACHINE/SECURITY && PS1='# ' || PS1='$ '
>
> Relies on the fact that Cygwin (unlike most non-Cygwin programs) enables
> SeBackupPrivilege if available.
>
> See also: http://cygwin.com/ml/cygwin/2012-02/msg00806.html
>
> Christian

I'll give that a go as a start. But, I would still like to see by
Cygwin uid shown as 0 when I am elevated. Because it's the same as the
windows equivalent of su.

Regards,

LL

--
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: Options for getting mandatory locking in cygwin1.dll (was: Promote sqlite 3.7.13-1 from test status?)


On 8/16/2012 6:26 AM, Corinna Vinschen wrote:

On Aug 16 06:01, Warren Young wrote:

Advisory locking only works when all players cooperate.  We can't
assume that on Windows, unless we set up an insular Cygwin ghetto.


So, are you saying that Cygwin should use mandatory file locking?


Of course not.  That would be a disaster.


You are aware that there's no chance at all to implement the UNIX
locking API calls correctly this way since Windows locking has nothing
in common with UNIX locking except for the word "locking".


Not even on a per-process basis (cygwin_set_mandatory_locking(1)), in 
conjunction with fcntl(F_SETLK)?  That's how SQLite's unixFileLock() 
function is implemented.


That is, this proposal would put the DLL in a mode where it called 
LockFileEx() to establish the reader/writer lock byte ranges instead of 
using its private advisory locking scheme.


Alternately, Cygwin could follow Linux and implement 'mount -o mand'. 
You could get mandatory locking on just your svn checkout tree this way, 
for example.  It would apply to all Cygwin programs, not just 
svn/SQLite, but it shouldn't be any more problematic than normal day to 
day Windows use.  Cygwin programs not run within that mount wouldn't be 
affected.


I'm aware that fcntl(F_SETLK) isn't thread-safe[1] but we're arguing "if 
it's good enough for Unix, it's good enough for Cygwin" here, aren't we? 
 The other objection in reference [1] is that it doesn't work with NFS, 
which doesn't matter to us here, I think.


If neither of those proposals will work, I think we'll have no choice 
but to continue to try and chase a SQLite specific solution.  You can't 
fix it on the Windows native side of things.  I doubt you can fix it in 
Subversion, and even if you could, that's no better than fixing it in 
SQLite.  Worse, actually, because then you've got a fix that affects 
only one program, not all SQLite dependents.



[1] http://0pointer.de/blog/projects/locking.html

--
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 test snapshots

2012-08-16 Thread Ken Brown


On 8/16/2012 3:26 PM, Christopher Faylor wrote:

On Thu, Aug 16, 2012 at 03:11:34PM -0400, Ken Brown wrote:

With the current snapshot (20120816 17:19:27), I have problems with
emacs-X11.exe.  When I start it under X (by typing 'emacs&' in an xterm
window), its CPU usage goes up to 50% and its window never displays.
The attached file gives the result of attaching gdb and giving the
command 'thread apply all bt full'.

I reproduced this running emacs under mintty, but it took longer for it
to happen.

The problem doesn't occur with the 20120815 snapshot.


It's funny how the simple explanation of a problem can trigger a
"Oh #(*&$.  I know what I did."

In this case, I made my standard "reverse the sense of a ? operator"
mistake.

I'm generating a new snapshot which seems to fix the problem.


Confirmed.  Thanks.

Ken


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

Re: Question about UAC and bash/cygwin

On Thu, Aug 16, 2012 at 3:00 PM, Christian Franke
 wrote:
> Corinna Vinschen wrote:
>>
>> On Aug 16 07:06, Lord Laraby wrote:
>-8
>>
>> What is it good for to have uid 0?  You want to know if you have admin
>> rights, so why don't you simply check for the admin group in the
>> supplementary group list?
>>
>> Here's what I do in my tcsh ~/.cshrc profile to set the prompt:
>>
>>id -G | egrep -q '\<544\>' && set prompt = '#  || set prompt = '\$ '
>>
>>
>
> I use this simple check which does not depend on /etc/group contents:
>
>  test -r /proc/registry/HKEY_LOCAL_MACHINE/SECURITY && PS1='# ' || PS1='$ '
>
> Relies on the fact that Cygwin (unlike most non-Cygwin programs) enables
> SeBackupPrivilege if available.
>
> See also: http://cygwin.com/ml/cygwin/2012-02/msg00806.html
>
> Christian

I'll give that a go as a start. But, I would still like to see by
Cygwin uid shown as 0 when I am elevated. Because it's the same as the
windows equivalent of su.

Regards,

LL

--
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 test snapshots

On Thu, Aug 16, 2012 at 03:11:34PM -0400, Ken Brown wrote:
>With the current snapshot (20120816 17:19:27), I have problems with 
>emacs-X11.exe.  When I start it under X (by typing 'emacs&' in an xterm 
>window), its CPU usage goes up to 50% and its window never displays. 
>The attached file gives the result of attaching gdb and giving the 
>command 'thread apply all bt full'.
>
>I reproduced this running emacs under mintty, but it took longer for it 
>to happen.
>
>The problem doesn't occur with the 20120815 snapshot.

It's funny how the simple explanation of a problem can trigger a
"Oh #(*&$.  I know what I did."

In this case, I made my standard "reverse the sense of a ? operator"
mistake.

I'm generating a new snapshot which seems to fix the problem.

I meant to run my normal raft of exhaustive tests:

- run bash in console
- run mintty
- run X
- start emacs

but I missed the last two.  Duh.

cgf

--
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 test snapshots

2012-08-16 Thread Ken Brown


On 8/16/2012 2:37 PM, Christopher Faylor wrote:

On Tue, Aug 14, 2012 at 12:48:03PM +, Adam Dinwoodie wrote:

Christopher Faylor wrote:

On Fri, Aug 10, 2012 at 06:31:25AM +, Achim Gratz wrote:

Daniel Colascione writes:

It works for me in bash.  I don't have tcsh installed, but I don't see why
SIGINT would work differently there.


Yes, it works in bash for me, too.  Tcsh does something that apparently
breaks with the new snapshot, but since I don't get any error messages, it's
hard to tell what that might be.


You're not really giving us much to go on.  I've tried ping (both Windows and
Cygwin version) under tcsh and both work fine.  And, the small snippet that
you cut/paste in your original bug report clearly showed that ping was
responding to CTRL-C.


I'm still using this snapshot (I've had no reason to stop until now),
and have hit this issue two out of the last five times running Cygwin
ping.  The ping process is still visible in Process Explorer after
hitting ^C.  There's no obvious difference between when ^C terminates
the process and when it doesn't.


I managed to duplicate this once a couple of days ago in a mintty/tcsh
process but I had a very hard time consistently hitting it.  So I wrote
a test case which ran ping repeatedly in a loop under mintty while another
process killed it.  Eventually, I could duplicate the problem in a few
minutes.  There were two problems, one illustrated by the "sigwaitinfo"
mentioned in another thread and another caused by a race.

After making some changes to signal handling, I ran the test case for an
afternoon without issue.

The current snapshot has these changes.


With the current snapshot (20120816 17:19:27), I have problems with 
emacs-X11.exe.  When I start it under X (by typing 'emacs&' in an xterm 
window), its CPU usage goes up to 50% and its window never displays. 
The attached file gives the result of attaching gdb and giving the 
command 'thread apply all bt full'.


I reproduced this running emacs under mintty, but it took longer for it 
to happen.


The problem doesn't occur with the 20120815 snapshot.

Ken

Thread 10 (Thread 5884.0x17c4):
#0  0x76f6000d in ntdll!LdrFindResource_U () from /c/windows/SysWOW64/ntdll.dll
No symbol table info available.
#1  0x76fef896 in ntdll!RtlQueryTimeZoneInformation ()
   from /c/windows/SysWOW64/ntdll.dll
No symbol table info available.
#2  0x7375eb68 in ?? ()
No symbol table info available.
#3  0x in ?? ()
No symbol table info available.

Thread 9 (Thread 5884.0x9a0):
#0  0x76f71f26 in ntdll!LdrQueryProcessModuleInformation ()
   from /c/windows/SysWOW64/ntdll.dll
No symbol table info available.
#1  0x76f71f26 in ntdll!LdrQueryProcessModuleInformation ()
   from /c/windows/SysWOW64/ntdll.dll
No symbol table info available.
#2  0x76fa3352 in ntdll!RtlCreateTagHeap () from /c/windows/SysWOW64/ntdll.dll
No symbol table info available.
warning: (Internal error: pc 0x1b7 in read in psymtab, but not in symtab.)

warning: (Internal error: pc 0x1b7 in read in psymtab, but not in symtab.)

#3  0x01b8 in ?? ()
warning: (Internal error: pc 0x1b7 in read in psymtab, but not in symtab.)

No symbol table info available.
warning: (Internal error: pc 0x1b7 in read in psymtab, but not in symtab.)

#4  0x044dac8c in ?? ()
No symbol table info available.
#5  0x6100538d in _cygtls::call2 (this=, func=0x2, 
arg=0x18c9908, buf=0x6100551b)
at /netrel/src/cygwin-snapshot-20120816-1/winsup/cygwin/cygtls.cc:99
res = 
#6  0x044dff88 in ?? ()
No symbol table info available.
#7  0x74f3339a in KERNEL32!BaseCleanupAppcompatCacheSupport ()
   from /c/windows/syswow64/kernel32.dll
No symbol table info available.
#8  0x018c9908 in ?? ()
No symbol table info available.
#9  0x76f89ef2 in ntdll!RtlpNtSetValueKey () from /c/windows/SysWOW64/ntdll.dll
No symbol table info available.
#10 0x018c9908 in ?? ()
No symbol table info available.
#11 0x76f89ec5 in ntdll!RtlpNtSetValueKey () from /c/windows/SysWOW64/ntdll.dll
No symbol table info available.
#12 0x6107f110 in cygwin_inet_network () from /usr/bin/cygwin1.dll
No symbol table info available.
#13 0x in ?? ()
No symbol table info available.

Thread 8 (Thread 5884.0xc58):
#0  0x76f71f26 in ntdll!LdrQueryProcessModuleInformation ()
   from /c/windows/SysWOW64/ntdll.dll
No symbol table info available.
#1  0x76f71f26 in ntdll!LdrQueryProcessModuleInformation ()
   from /c/windows/SysWOW64/ntdll.dll
No symbol table info available.
#2  0x76fa3352 in ntdll!RtlCreateTagHeap () from /c/windows/SysWOW64/ntdll.dll
No symbol table info available.
warning: (Internal error: pc 0x1c3 in read in psymtab, but not in symtab.)

warning: (Internal error: pc 0x1c3 in read in psymtab, but not in symtab.)

warning: (Internal error: pc 0x1c3 in read in psymtab, but not in symtab.)

#3  0x01c4 in ?? ()
warning: (Internal error: pc 0x1c3 in read in psymtab, but not in symtab.)

No sy

Re: Question about UAC and bash/cygwin

2012-08-16 Thread Christian Franke


Corinna Vinschen wrote:

On Aug 16 07:06, Lord Laraby wrote:

  My, major emphasis is recognizing in the Cygwin dll
or startup code somewhere) that the user has full Administrator rights
and simply replacing his normal UID with 0 (or that of whomever root
seems to be by /etc/passwd). Internally (at cygwin.dll level) he/she
is still the same user, but the desired effects would be that bash and
others might change his prompt to '#' and that scripts can check for
admin rights and files he/she created would become owned by UID 0 (or
the Administrators group).

What is it good for to have uid 0?  You want to know if you have admin
rights, so why don't you simply check for the admin group in the
supplementary group list?

Here's what I do in my tcsh ~/.cshrc profile to set the prompt:

   id -G | egrep -q '\<544\>' && set prompt = '#  || set prompt = '\$ '




I use this simple check which does not depend on /etc/group contents:

 test -r /proc/registry/HKEY_LOCAL_MACHINE/SECURITY && PS1='# ' || PS1='$ '

Relies on the fact that Cygwin (unlike most non-Cygwin programs) enables 
SeBackupPrivilege if available.


See also: http://cygwin.com/ml/cygwin/2012-02/msg00806.html

Christian


--
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: Another sigwaitinfo problem (with testcase)

On Tue, Aug 14, 2012 at 10:36:39PM -0700, Daniel Colascione wrote:
>When run on a Linux machine, this program starts up and blocks on sigwaitinfo.
>You can suspend and resume the program using usual job control facilities, and
>on SIGINT, the program prints a message and exits. When the program resumes
>after being stopped, it prints "resumed".
>
>With the 2012-08-07 Cygwin snapshot, this program prints "resumed" immediately
>after receiving SIGTSTP, then fails to respond to any signal, even signals not
>in the blocked set. A simpler test program that just calls "raise (SIGSTOP)"
>property stops itself before resuming execution.

This should be fixed in the latest snapshot.

Thanks for the test case.

cgf

--
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 test snapshots

On Tue, Aug 14, 2012 at 12:48:03PM +, Adam Dinwoodie wrote:
>Christopher Faylor wrote:
>>On Fri, Aug 10, 2012 at 06:31:25AM +, Achim Gratz wrote:
>>>Daniel Colascione writes:
It works for me in bash.  I don't have tcsh installed, but I don't see why
SIGINT would work differently there.
>>>
>>>Yes, it works in bash for me, too.  Tcsh does something that apparently
>>>breaks with the new snapshot, but since I don't get any error messages, it's
>>>hard to tell what that might be.
>>
>>You're not really giving us much to go on.  I've tried ping (both Windows and
>>Cygwin version) under tcsh and both work fine.  And, the small snippet that
>>you cut/paste in your original bug report clearly showed that ping was
>>responding to CTRL-C.
>
>I'm still using this snapshot (I've had no reason to stop until now),
>and have hit this issue two out of the last five times running Cygwin
>ping.  The ping process is still visible in Process Explorer after
>hitting ^C.  There's no obvious difference between when ^C terminates
>the process and when it doesn't.

I managed to duplicate this once a couple of days ago in a mintty/tcsh
process but I had a very hard time consistently hitting it.  So I wrote
a test case which ran ping repeatedly in a loop under mintty while another
process killed it.  Eventually, I could duplicate the problem in a few
minutes.  There were two problems, one illustrated by the "sigwaitinfo"
mentioned in another thread and another caused by a race.

After making some changes to signal handling, I ran the test case for an
afternoon without issue.

The current snapshot has these changes.

I'd appreciate feedback on whether or not this fixes this problem.

cgf

--
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: Cygwin crashes in kill_pgrp, _pinfo truncation issue.

On Thu, Aug 16, 2012 at 08:20:37PM +0400, Andrey Khalyavin wrote:
>On Wed, 15 Aug 2012 10:11:16 -0400, Christopher Faylor wrote:
>>On Wed, Aug 15, 2012 at 04:54:42PM +0400, Andrey Khalyavin wrote:
>>>I finally got a cygwin crash dump from our build bots. It shows, that
>>>cygwin1.dll crashes in kill_pgrp function on line:
>>>   (pid > 1 && p->pgid != pid) ||
>>>where p is a pointer to _pinfo. This function enumerates all _pinfo's
>>>and executes this line for all of them which pass p->exists() check.
>>>In crash dump p points to _pinfo that has process_state equal to
>>>PID_IN_USE | PID_EXECED.
>>
>>Thanks for tracking this down.  I've added a check for "execed" to
>>_pinfo::exists.
>>
>>cgf
>I updated core libraries from 20120803 snapshot to 20120815 snapshot
>and now bash crashes when I execute rm -rf dir. Reproducibility is
>strange. It crashed for hours when I entered
>cd /tmp
>mkdir a
>rm -rf a
>commands but now suddenly stopped crashing in this case.
>It is still crashes on rm -rf in the real script we use though.
>
>Crash happens in setup_handler function on line
> HANDLE hth = (HANDLE) *tls;
>because tls->tid equals to zero. Definition of this operation is in
>sygtls.h: operator HANDLE () const {return tid->win32_obj_id;}.
>setup_handler is called from sigpacket::process which in turn
>called from wait_sig. Signal number is 20, signal code is 28.
>All fields of tls structure are zero with exception stacklock equal
>to 1 and stackptr equal to address of tls->stack.

Sounds like a race between thread creation and signal handling.  I have
added some defensive code in the latest snapshot.

cgf

--
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: Promote sqlite 3.7.13-1 from test status?


On 8/16/2012 10:34 AM, Brian Wilson wrote:


Corina


Corinna.


is correct, Cygwin is supposed to be a Posix compliant environment


It's also supposed to interoperate with native Windows programs.


If you want to use Windoze tools, why are you using Cygwin?


First, instant 100 point credibility penalty for being puerile.

Second, the whole reason for using Cygwin is so you could have a 
Linux/POSIX environment *on Windows.*  If you have no need for Windows 
programs and want a Cygwin-like environment, wouldn't you be running 
Linux, or a BSD, or OS X, or Solaris, or...?


Okay, so you come back saying something about how there should be some 
Chinese Wall between the Cygwin and native Windows lands.  In that case, 
I recommend you install one of the above-named OSes in a VM.  It'll be 
faster and more featureful.


I'm actually struggling to come up with a reason why you would *ever* 
run Cygwin if you didn't ever want it to touch the native Windows side 
of things, or vice versa.  I guess it uses less RAM and starts up faster 
than a VM



you really must, why not set up Apache under Cygwin and access the Cygwin
Subversion repository through the defined http server interface and the
issue of file locking becomes moot.


1. That wouldn't provide all the features some people want.  TortoiseSVN 
provides a really nice version tree and a spiffy graphical diff 
facility, for example.


2. As David said, we're not talking about locks in the repository itself 
here.  We're talking about a lock on the .svn/wc.db file at the top of 
the client-side checkout tree, introduced in svn 1.7.



As a worst case scenario, why can't the direct SVN access locking behavior
be determined by setting an environment variable.


Because there's no easy way to do that.

You can't compile SQLite for *both* for Windows and Unix at the same 
time.  The code simply isn't structured to let you swap I/O subsystems 
in and out like that.


I could instead disentangle Windows, Cygwin and Unix in the SQLite code, 
and make the Cygwin code switch-hit between locking methods.  But keep 
in mind, the only reason I maintain the SQLite package is that I know 
what it is and how to test it, so I rescued it from being removed from 
the Cygwin distro back when its previous maintainer abandoned it.  I 
simply don't care enough about it to bother with such a big rewrite.  It 
doesn't help that upstream has ignored multiple requests to integrate 
trivial patches for it.  I expect they'd be certain to ignore a big one 
like this, so I'd then have to keep tracking upstream changes to 
reintegrate it each time.


Bottom line, the only options open to you while I'm maintainer are 
trivial patches and build system changes.


I suppose I could release *two* versions of SQLite, one for each build 
method.  I'd still nominate the Windows-aware version as the default.


I'm not sure setup.exe's dependency resolution code can cope with this, 
however.  I don't recall hearing anything about features like RPM's 
"Provides", which lets two different package provide a given facility, 
interchangeably.  If not, then the nonstandard package would have to be 
made available for manual download only, to be unpacked by hand and kept 
up to date by hand each time setup.exe overwrites it with a new version. 
 Blech.


--
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: Question about UAC and bash/cygwin

On Aug 16 11:06, Lord Laraby wrote:
> On Thu, Aug 16, 2012Corinna Vinschen
> > On Aug 16 08:48, Lord Laraby wrote:
> >> On Thu, Aug 16, 2012 Corinna Vinschen wrote:
> >> > On Aug 16 07:06, Lord Laraby wrote:
> >>
> >> See, here where I said I want to know if the user is in fact
> >> "elevated"?  I'm always a member of the Administrators Group (group
> >> 544) even when I have no such privileges to "administer" the system.
> >>
> >> > What is it good for to have uid 0?  You want to know if you have admin
> >> > rights, so why don't you simply check for the admin group in the
> >> > supplementary group list?
> >>
> >> The uid 0 feature is just a unixy way of indicating that my account
> >> has already passed and accepted the UAC and I'm now running as a
> >> normal admin (not a puny user).
> >>
> > Huh?  When you're not running elevated, the admin group will not be in
> > the list of supplementary groups.  What other information do you need?
> > What's the problem?
> >
> >
> > Corinna
> 
> Apparently, we're seeing completely different things then. Here's two
> examples I ran one normally and one elevated.
> 
> 
> non-elevated:
> master@Master-PC ~
> $ cd /etc/at-spi2/
> 
> master@Master-PC /etc/at-spi2
> $ id
> uid=1001(master) gid=0(root)
> groups=0(root),545(users),1007(hlplibrupdaters),1000(homegrp),513(none)
> Note ^^^

I question that this is a non-elevated shell.  Or your /etc/group file
is broken somehow.  Why, for instance, is the group 544 missing?  This
looks a bit like you changed /etc/passwd and /etc/group and screwed up
somehow.  Revert both files to the default and start over.

Again, if you're running under UAC control in a non-elevated shell, then
the local admin group is not in your Windows user token(*) and therefore
is not in the supplementary group list.

> See, root (545) is on my groups all the time - elevated or not. Unless

545 is "users", not "root".  The problem is that I can't look over your
shoulders.  What you could do is to run

  /cygdrive/c/Windows/System32/whoami /all

in both, a non-elevated and an elevated shell and look for the group
list and user rights.  These, ultimately, dictate what you can and what
you can't do in a session.  Cygwin has nothing to do with that, except
that it enables certain user rights which are disabled by default.

Corinna

(*) Actually that statement is *very* much simplified.  In fact the admin
group is in the user's token of a non-elevated process as well.  But
it's marked as "for deny only", so the group entry doesn't give any
admin rights.  CYgwin checks for this and doesn't add deny-only
groups to the supplementary group list.

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  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

Re: Question about UAC and bash/cygwin

2012-08-16 Thread Kurt Franke

Lord Laraby  gmail.com> writes:

> 
> On Thu, Aug 16, 2012Corinna Vinschen
> > On Aug 16 08:48, Lord Laraby wrote:
> >> On Thu, Aug 16, 2012 Corinna Vinschen wrote:
> >> > On Aug 16 07:06, Lord Laraby wrote:
> >>
> >> See, here where I said I want to know if the user is in fact
> >> "elevated"?  I'm always a member of the Administrators Group (group
> >> 544) even when I have no such privileges to "administer" the system.
> >>
> >> > What is it good for to have uid 0?  You want to know if you have admin
> >> > rights, so why don't you simply check for the admin group in the
> >> > supplementary group list?
> >>
> >> The uid 0 feature is just a unixy way of indicating that my account
> >> has already passed and accepted the UAC and I'm now running as a
> >> normal admin (not a puny user).
> >>
> > Huh?  When you're not running elevated, the admin group will not be in
> > the list of supplementary groups.  What other information do you need?
> > What's the problem?
> >
> >
> > Corinna
> 
> Apparently, we're seeing completely different things then. Here's two
> examples I ran one normally and one elevated.
> 
> non-elevated:
> master  Master-PC ~
> $ cd /etc/at-spi2/
> 
> master  Master-PC /etc/at-spi2
> $ id
> uid=1001(master) gid=0(root)
> groups=0(root),545(users),1007(hlplibrupdaters),1000(homegrp),513(none)
> Note ^^^
> 
> master  Master-PC /etc/at-spi2
> $ ls -l
> total 4
> -rw-r--r-- 1 admin none 1335 May 15 03:27 accessibility.conf
> 
> master  Master-PC /etc/at-spi2
> $ mv accessibility.conf accessibility.conf.tmp
> mv: cannot move `accessibility.conf' to `accessibility.conf.tmp':
> Permission denied
> 
> ^^^ Not able to bypass ACL (but note being in group 0 (544)
> 
> *** Now try in elevated mode
> Elevated:
> master  Master-PC ~
> $ id
> uid=1001(master) gid=0(root)
> groups=0(root),545(users),1007(hlplibrupdaters),1000(homegrp),513(none)
> 
> master  Master-PC ~
> $ cd /etc/at-spi2/
> 
> master  Master-PC /etc/at-spi2
> $ ls -l
> total 4
> -rw-r--r-- 1 admin none 1335 May 15 03:27 accessibility.conf
> 
> master  Master-PC /etc/at-spi2
> $ mv accessibility.conf accessibility.conf.sav
> 
> ^^^ No error and successfully used admin provileges...
> 
> master  Master-PC /etc/at-spi2
> $ mv accessibility.conf.sav accessibility.conf
> 
> ^^^ Again
> 
> master  Master-PC /etc/at-spi2
> $ ls -l
> total 4
> -rw-r--r-- 1 admin none 1335 May 15 03:27 accessibility.conf
> 
> master  Master-PC /etc/at-spi2
> $ id
> uid=1001(master) gid=0(root)
> groups=0(root),545(users),1007(hlplibrupdaters),1000(homegrp),513(none)
> Note ^^^
> master  Master-PC /etc/at-spi2
> 
> 
> See, root (545) is on my groups all the time - elevated or not. Unless
> this is an error of some magnitude that it was inadvertently changed,
> I cannot say.
> 
> Needless to say, as you can see from the sample out above, I can only
> do certain things elevated (admin-type tasks) regardless of having
> root in my groups.
> 
> Any suggestions on why I get different results?
> 
> LL
> 

Hi,

I got a hint how to do this on this list some years ago by Brian Dessent.
The function CheckTokenMembership() must be called for this liek done in 
the following program:

= +++ CheckTokenMembership-Admin.c =

#include 
#define _WIN32_WINNT 0x0500
#include 

int main (int argc, char **argv)
{
  SID_IDENTIFIER_AUTHORITY NtAuthority = {SECURITY_NT_AUTHORITY};
  PSID AdministratorsGroup;
  BOOL isAdmin;

  if (AllocateAndInitializeSid (&NtAuthority, 2,
  SECURITY_BUILTIN_DOMAIN_RID, DOMAIN_ALIAS_RID_ADMINS,
  0, 0, 0, 0, 0, 0, &AdministratorsGroup) == 0 ||
  CheckTokenMembership (NULL, AdministratorsGroup, &isAdmin) == 0)
{
  printf ("failed with win32 error %lu\n", GetLastError ());
  exit (2);
}

  FreeSid (AdministratorsGroup);
  exit (!isAdmin);
}

= --- CheckTokenMembership-Admin.c =

Its exit value indicates if admin token is active or not - speaking 
elevated or not:

0 : elevated
1 : not elevated



I use a script around it for calling to allow handling for windows 
versions which doesn't support the CheckTokenMembership() function.
If version is less than NT-6.0 or if the program is not found in path
it uses the traditional methode of checking for Administrators group
membership and returns with an exit value of to for "possible elevated"
if membership exists and the windows version is NT-6.0 or greater


= +++ isAdmin =
#! /bin/bash

# check if running with admin privileges
# to make the check language independent use group id's not names
# get the adminstrators group id's from /etc/group checking for lines
# holding wellknown sid ':S-1-5-32-544:' ind second field

is_NT=`uname | grep CYGWIN_NT | wc -l`

if [ $is_NT -gt 0 ]
then
  NT_version=`uname | cut -d- -f2`
else
  NT_version="-1.0"
fi

NT_main_version=`echo $NT_version | cut -d. -f1`

if [ $is_NT -gt 0 -a $NT_main_versi

Re: Promote sqlite 3.7.13-1 from test status?

2012-08-16 Thread David Rothenberger

On 8/16/2012 9:34 AM, Brian Wilson wrote:
> Corina is correct, Cygwin is supposed to be a Posix compliant environment so 
> the SQLite package should follow the Posix standard as the default 
> behavior.  If you want to use Windoze tools, why are you using Cygwin?  If 
> you really must, why not set up Apache under Cygwin and access the Cygwin 
> Subversion repository through the defined http server interface and the 
> issue of file locking becomes moot.

The locking issue isn't only related to the repository, it's related to
the workspace itself. The problem people have is when they use
TortoiseSVN and Cygwin svn with the same workspace.

> If this solution isn't acceptable, Cygwin Subversion should use a
> different DB and drop SQLite.

As the current Subversion svn packager, I can say I'm not going to do
that. Subversion upstream only supports SQLite.

>From a Subversion perspective, I think turning off the TortoiseSVN icon
cache is a reasonable work-around for those that must use both tools.
But as Warren pointed out, Subversion may not be the only case when a
Cygwin tool and a Windows tool want to access the same database at the
same time. I can understand the point that Cygwin SQLite should be
behave POSIX-ly, but if the locking is handled solely within SQLite
itself, does it really matter? Using the same locking that
Windows-native SQLite uses does seem to avoid some interaction issues
without causing any issues for Cygwin programs, so that's a net plus, right?

-- 
David Rothenberger    daver...@acm.org

genius, n.:
Person clever enough to be born in the right place at the right
time of the right sex and to follow up this advantage by saying
all the right things to all the right people.

--
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: Promote sqlite 3.7.13-1 from test status?

2012-08-16 Thread Brian Wilson


> >> This recent wish for SQLite on Cygwin to act more Unix-like is the
> >> first such request I've received, and I don't remember it being an
> >> issue with the previous maintainer, either.
> >
> > Maybe the reason is because subversion didn't use SQLite before?
> 
> That's mere happenstance.  There's nothing special about Subversion 
> in this regard.  It could have happened with any other pair of 
> SQLite based programs.  The fact that it hasn't until now means the 
> DITCW principle isn't buying us much in this case.
> 
> Understand Corinna, I see your point, and Achim's.  Remember that I 
> accepted Achim's patch and released 3.7.12.1-1 including it.  Making 
> Cygwin SQLite behave in a POSIXy way feels right.  But, given that 
> the new locking behavior causes actual people actual problems, 
> purity alone isn't looking like such a good reason to keep the new 
behavior.
> 
> If we discard purity as a reason to do this, all we're left with is 
> the actual problem brought up by one person (Achim) in N years.  We 
> can't solve that problem without causing problems for many others.
> 
> > This behaviour breaks concurrency with other Cygwin executables
> > using POSIX calls for file locking.
> 
> I agree, in principle, the 3.7.3/13-1 locking behavior is Wrong (tm).
> 
> >> Advisory locking only works when all players cooperate.  We can't
> >> assume that on Windows, unless we set up an insular Cygwin ghetto.
> >
> > So, are you saying that Cygwin should use mandatory file locking?
> 
> In a situation like this, you have three choices:
> 
> 1. Use mandatory locking in the Cygwin program.  Ugly, but useful 
> work gets done.
> 
> 2. Tell all users of the Cygwin program to stop using the native 
> Windows program or switch to a Cygwin alternative.  This is a bad 
> choice as a rule, since it tells the world Cygwin doesn't play well 
> with others. It's worse in this case due to N years of the Cygwin 
> program playing well with the Windows program.  Additionally, there 
> is no GUI Subversion client in the Cygwin package repo.
> 

Corina is correct, Cygwin is supposed to be a Posix compliant environment so 
the SQLite package should follow the Posix standard as the default 
behavior.  If you want to use Windoze tools, why are you using Cygwin?  If 
you really must, why not set up Apache under Cygwin and access the Cygwin 
Subversion repository through the defined http server interface and the 
issue of file locking becomes moot.

Cygwin is not a Windoze/Posix program compatability matching system; it is a 
Posix environment on the Windoze platform.  There is no intention to have 
Windoze only application work directly to Cygwin applications (nor is there 
an intention to prevent this either).

As a worst case scenario, why can't the direct SVN access locking behavior 
be determined by setting an environment variable.  If users want it to work 
with Windoze programs (i.e. in a non-posix way), have them set an 
environment variable for hard locks; other wise, let the rest of us who want 
a Posix experience use the advisory locks.  If this solution isn't 
acceptable, Cygwin Subversion should use a different DB and drop SQLite.

Sincerely,

Brian S. Wilson


--
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: Cygwin crashes in kill_pgrp, _pinfo truncation issue.

2012-08-16 Thread Andrey Khalyavin

On Wed, 15 Aug 2012 10:11:16 -0400, Christopher Faylor wrote:
>On Wed, Aug 15, 2012 at 04:54:42PM +0400, Andrey Khalyavin wrote:
>>I finally got a cygwin crash dump from our build bots. It shows, that
>>cygwin1.dll crashes in kill_pgrp function on line:
>>(pid > 1 && p->pgid != pid) ||
>>where p is a pointer to _pinfo. This function enumerates all _pinfo's
>>and executes this line for all of them which pass p->exists() check.
>>In crash dump p points to _pinfo that has process_state equal to
>>PID_IN_USE | PID_EXECED.
>
>Thanks for tracking this down.  I've added a check for "execed" to
>_pinfo::exists.
>
>cgf
I updated core libraries from 20120803 snapshot to 20120815 snapshot
and now bash crashes when I execute rm -rf dir. Reproducibility is
strange. It crashed for hours when I entered
cd /tmp
mkdir a
rm -rf a
commands but now suddenly stopped crashing in this case.
It is still crashes on rm -rf in the real script we use though.

Crash happens in setup_handler function on line
  HANDLE hth = (HANDLE) *tls;
because tls->tid equals to zero. Definition of this operation is in
sygtls.h: operator HANDLE () const {return tid->win32_obj_id;}.
setup_handler is called from sigpacket::process which in turn
called from wait_sig. Signal number is 20, signal code is 28.
All fields of tls structure are zero with exception stacklock equal
to 1 and stackptr equal to address of tls->stack.

I don't understand what goes wrong here. Can you suggest what
I can look for in the debugger?

Andrey Khalyavin

--
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 service needs to be restarted after every boot

2012-08-16 Thread Jörg Gerlach


Am 16.08.2012 11:05, schrieb Andrey Repin:

Greetings, Jörg Gerlach!

I did mean that, and now, that you confirmed it, the situation slowly 
driving into the land of BLODA. Do you have custom firewall/AV with 
TCP/IP filtering capabilities installed? -- WBR, Andrey Repin 
(anrdae...@freemail.ru) 16.08.2012, <13:04> Sorry for my terrible 
english... 


The only difference was that Threatfire was installed on this Windows 
System but I have allready tried it on an virtual machine with 
Threatfire and there it works fine. Except of the Windows firewall I 
only have installed Avira Antivirus but that runs on all systems.


Best regards,
Jörg Gerlach.

--
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: Promote sqlite 3.7.13-1 from test status?


On 8/16/2012 6:26 AM, Corinna Vinschen wrote:

On Aug 16 06:01, Warren Young wrote:


This recent wish for SQLite on Cygwin to act more Unix-like is the
first such request I've received, and I don't remember it being an
issue with the previous maintainer, either.


Maybe the reason is because subversion didn't use SQLite before?


That's mere happenstance.  There's nothing special about Subversion in 
this regard.  It could have happened with any other pair of SQLite based 
programs.  The fact that it hasn't until now means the DITCW principle 
isn't buying us much in this case.


Understand Corinna, I see your point, and Achim's.  Remember that I 
accepted Achim's patch and released 3.7.12.1-1 including it.  Making 
Cygwin SQLite behave in a POSIXy way feels right.  But, given that the 
new locking behavior causes actual people actual problems, purity alone 
isn't looking like such a good reason to keep the new behavior.


If we discard purity as a reason to do this, all we're left with is the 
actual problem brought up by one person (Achim) in N years.  We can't 
solve that problem without causing problems for many others.



This behaviour breaks concurrency with other Cygwin executables
using POSIX calls for file locking.


I agree, in principle, the 3.7.3/13-1 locking behavior is Wrong (tm).

In practice, it breaks *one person's* program, while allowing many 
others' programs to work correctly.


It's not like I've refused to even try the pure path.  I did try it. 
Now that the experiment's been run and I want to revert that change, 
returning to the way it's been for *years*, you want me to keep the 
problematic change, and thus keep the problems.  Why would I?


If you're feeling adamant about this issue, you should take this 
package's maintainership away from me, and give it to someone who will 
do it the way you want.


Seriously.  No bluff, no rancor.  I already tried to persuade Achim to 
take over maintanership, since it seemed he cared a lot more about the 
Cygwin SQLite package than me.  He chose not to accept, but maybe he's 
still persuadable.



Advisory locking only works when all players cooperate.  We can't
assume that on Windows, unless we set up an insular Cygwin ghetto.


So, are you saying that Cygwin should use mandatory file locking?


In a situation like this, you have three choices:

1. Use mandatory locking in the Cygwin program.  Ugly, but useful work 
gets done.


2. Tell all users of the Cygwin program to stop using the native Windows 
program or switch to a Cygwin alternative.  This is a bad choice as a 
rule, since it tells the world Cygwin doesn't play well with others. 
It's worse in this case due to N years of the Cygwin program playing 
well with the Windows program.  Additionally, there is no GUI Subversion 
client in the Cygwin package repo.


3. Tell all users of the native Windows program to stop using the Cygwin 
program.  Again, it says Cygwin doesn't play well with others.


I suppose there's a fourth choice, where everyone refuses to budge and 
you get Palestine.  But, that's not going to happen here, because I've 
already told you you can take the West Bank if you want it.



Stop right here.  If the compatibility with native WIndows tools is more
important than the compatibility with POSIX and CYgwin POSIX tools with
each other, then why do we bother at all to implement POSIX calls in the
most POSIXy or Linuxy way possible?


In principle, yes, you're right.  But that's the problem with rigid 
principles: there are always specific breakdown cases where the 
principle causes more harm than good.  This is one of those cases.


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

Re: Question about UAC and bash/cygwin

On Thu, Aug 16, 2012Corinna Vinschen
> On Aug 16 08:48, Lord Laraby wrote:
>> On Thu, Aug 16, 2012 Corinna Vinschen wrote:
>> > On Aug 16 07:06, Lord Laraby wrote:
>>
>> See, here where I said I want to know if the user is in fact
>> "elevated"?  I'm always a member of the Administrators Group (group
>> 544) even when I have no such privileges to "administer" the system.
>>
>> > What is it good for to have uid 0?  You want to know if you have admin
>> > rights, so why don't you simply check for the admin group in the
>> > supplementary group list?
>>
>> The uid 0 feature is just a unixy way of indicating that my account
>> has already passed and accepted the UAC and I'm now running as a
>> normal admin (not a puny user).
>>
> Huh?  When you're not running elevated, the admin group will not be in
> the list of supplementary groups.  What other information do you need?
> What's the problem?
>
>
> Corinna

Apparently, we're seeing completely different things then. Here's two
examples I ran one normally and one elevated.


non-elevated:
master@Master-PC ~
$ cd /etc/at-spi2/

master@Master-PC /etc/at-spi2
$ id
uid=1001(master) gid=0(root)
groups=0(root),545(users),1007(hlplibrupdaters),1000(homegrp),513(none)
Note ^^^

master@Master-PC /etc/at-spi2
$ ls -l
total 4
-rw-r--r-- 1 admin none 1335 May 15 03:27 accessibility.conf

master@Master-PC /etc/at-spi2
$ mv accessibility.conf accessibility.conf.tmp
mv: cannot move `accessibility.conf' to `accessibility.conf.tmp':
Permission denied

^^^ Not able to bypass ACL (but note being in group 0 (544)

*** Now try in elevated mode
Elevated:
master@Master-PC ~
$ id
uid=1001(master) gid=0(root)
groups=0(root),545(users),1007(hlplibrupdaters),1000(homegrp),513(none)

master@Master-PC ~
$ cd /etc/at-spi2/

master@Master-PC /etc/at-spi2
$ ls -l
total 4
-rw-r--r-- 1 admin none 1335 May 15 03:27 accessibility.conf

master@Master-PC /etc/at-spi2
$ mv accessibility.conf accessibility.conf.sav

^^^ No error and successfully used admin provileges...

master@Master-PC /etc/at-spi2
$ mv accessibility.conf.sav accessibility.conf

^^^ Again

master@Master-PC /etc/at-spi2
$ ls -l
total 4
-rw-r--r-- 1 admin none 1335 May 15 03:27 accessibility.conf

master@Master-PC /etc/at-spi2
$ id
uid=1001(master) gid=0(root)
groups=0(root),545(users),1007(hlplibrupdaters),1000(homegrp),513(none)
Note ^^^
master@Master-PC /etc/at-spi2


See, root (545) is on my groups all the time - elevated or not. Unless
this is an error of some magnitude that it was inadvertently changed,
I cannot say.

Needless to say, as you can see from the sample out above, I can only
do certain things elevated (admin-type tasks) regardless of having
root in my groups.

Any suggestions on why I get different results?

LL

--
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: Question about UAC and bash/cygwin

On Aug 16 08:48, Lord Laraby wrote:
> On Thu, Aug 16, 2012 Corinna Vinschen wrote:
> > On Aug 16 07:06, Lord Laraby wrote:
> >>  My, major emphasis is recognizing in the Cygwin dll
> >> or startup code somewhere) that the user has full Administrator rights
> >> and simply replacing his normal UID with 0 (or that of whomever root
> >> seems to be by /etc/passwd). Internally (at cygwin.dll level) he/she
> >> is still the same user, but the desired effects would be that bash and
> >> others might change his prompt to '#' and that scripts can check for
> >> admin rights and files he/she created would become owned by UID 0 (or
> >> the Administrators group).
> 
> See, here where I said I want to know if the user is in fact
> "elevated"?  I'm always a member of the Administrators Group (group
> 544) even when I have no such privileges to "administer" the system.
> 
> > What is it good for to have uid 0?  You want to know if you have admin
> > rights, so why don't you simply check for the admin group in the
> > supplementary group list?
> 
> The uid 0 feature is just a unixy way of indicating that my account
> has already passed and accepted the UAC and I'm now running as a
> normal admin (not a puny user).
> 
> > Here's what I do in my tcsh ~/.cshrc profile to set the prompt:
> >
> >   id -G | egrep -q '\<544\>' && set prompt = '#  || set prompt = '\$ '
> >
> 
> I can set that. But then I'm still fooling myself if I am not running
> with escalated privileges, I'm no more 'root' than my cat is.

Huh?  When you're not running elevated, the admin group will not be in
the list of supplementary groups.  What other information do you need?
What's the problem?


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  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

RE: Promote sqlite 3.7.13-1 from test status?

2012-08-16 Thread Thrall, Bryan

Warren Young wrote on 2012-08-16: 
> Dev Fred likes to use the GUI TortoiseSVN client most of the time.
> (Fred is a little strange, but we like him anyway.)

My particular use case is 99% of the time, I use Cygwin SVN, but once in a 
while TortoiseSVN's revision graph is useful. I think what makes this a bigger 
problem than "Don't use Windows apps at the same time on the same files as you 
are using Cygwin on" is just having TortoiseSVN installed triggers the SQLite 
locking problem, so Fred or I might not have used TortoiseSVN all week but it's 
still interfering with Cygwin SVN because of its Windows Explorer hooks.

Turning TortoiseSVN's icon overlay caching to "Shell" (or "None") has fixed the 
problem for me, but I haven't tried SQLite compiled without the Windows file 
locking. IMHO, if that combination works (icon caching off, SQLite using Cygwin 
locking), that's the way to go.

>   What are Fred's options?
> Option 1: Download the native Windows Subversion port.  Sensible, but it
> means you have to use a crippled shell.

Apologies for being pedantic, but TortoiseSVN already provides Windows 
Subversion command line tools. Your point of the crippled shell stands, however 
:)

--
Bryan Thrall
Principal Software Engineer
FlightSafety International
bryan.thr...@flightsafety.com

Re: Promote sqlite 3.7.13-1 from test status?

2012-08-16 Thread Earnie Boyd

On Thu, Aug 16, 2012 at 8:26 AM, Corinna Vinschen wrote:
>
> That's not how it's supposed to be, as far as I'm concerned...
>

I can see both POV but the Cygwin POV is to DITCW (Do It The Cygwin
Way) which is the de facto correct answer regardless of your own POV.
So the WJM response is in fact a correct response but not one you wish
to here.

-- 
Earnie
-- https://sites.google.com/site/earnieboyd

--
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: Question about UAC and bash/cygwin

On Thu, Aug 16, 2012 Corinna Vinschen wrote:
> On Aug 16 07:06, Lord Laraby wrote:
>>  My, major emphasis is recognizing in the Cygwin dll
>> or startup code somewhere) that the user has full Administrator rights
>> and simply replacing his normal UID with 0 (or that of whomever root
>> seems to be by /etc/passwd). Internally (at cygwin.dll level) he/she
>> is still the same user, but the desired effects would be that bash and
>> others might change his prompt to '#' and that scripts can check for
>> admin rights and files he/she created would become owned by UID 0 (or
>> the Administrators group).

See, here where I said I want to know if the user is in fact
"elevated"?  I'm always a member of the Administrators Group (group
544) even when I have no such privileges to "administer" the system.

> What is it good for to have uid 0?  You want to know if you have admin
> rights, so why don't you simply check for the admin group in the
> supplementary group list?

The uid 0 feature is just a unixy way of indicating that my account
has already passed and accepted the UAC and I'm now running as a
normal admin (not a puny user).

> Here's what I do in my tcsh ~/.cshrc profile to set the prompt:
>
>   id -G | egrep -q '\<544\>' && set prompt = '#  || set prompt = '\$ '
>

I can set that. But then I'm still fooling myself if I am not running
with escalated privileges, I'm no more 'root' than my cat is.

> Corinna
>

Thanks for the advice though. I'll work on something to get what I am seeking.

Regards,
~~
LL

--
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: Promote sqlite 3.7.13-1 from test status?

On Aug 16 06:01, Warren Young wrote:
> On 8/16/2012 4:55 AM, Corinna Vinschen wrote:
> >On Aug 16 04:30, Warren Young wrote:
> >>
> >>So, what you did with that requested change, Achim, is prevented
> >>Cygwin svn from winning any fights over ownership of .svn/wc.db.
> >
> >So what?  Don't use native Windows tools in parallel accessing the
> >same file.  Full stop.
> 
> I've been maintaining the Cygwin SQLite package for four years now.
> This recent wish for SQLite on Cygwin to act more Unix-like is the
> first such request I've received, and I don't remember it being an
> issue with the previous maintainer, either.

Maybe the reason is because subversion didn't use SQLite before?
This change only took place with the update from subversion 1.6 to
1.7.

> But, shortly after making the change -- because I didn't immediately
> see why it would hurt anything -- complaints started pouring in from
> actual people who've been doing what you say they shouldn't do.
> 
> So what's a package maintainer to do?  Go all WJM on them? :)
> 
> I don't see why I should break previously working behavior just out
> of purity, given that, so far, only one person ever in the entire
> world has been bothered enough by that lack of purity to ask me to
> change how SQLite is compiled.

This behaviour breaks concurrency with other Cygwin executables
using POSIX calls for file locking.

> >Why should mandatory locking be better here, while it's quite naturally
> >using advisory locking in the entire UNIX world?
> 
> Because that's what a native Windows build of SQLite does.
> 
> (Why?  Because https://sqlite.org/faq.html#q5)
> 
> Advisory locking only works when all players cooperate.  We can't
> assume that on Windows, unless we set up an insular Cygwin ghetto.

So, are you saying that Cygwin should use mandatory file locking?
You are aware that there's no chance at all to implement the UNIX
locking API calls correctly this way since Windows locking has nothing
in common with UNIX locking except for the word "locking".

> >If you think it's absolutely necessary to use some Windows
> >functions, what is it, and why?
> 
> The scenario is this:
> 
> Dev Fred likes to use the GUI TortoiseSVN client most of the time.
> (Fred is a little strange, but we like him anyway.)

Stop right here.  If the compatibility with native WIndows tools is more
important than the compatibility with POSIX and CYgwin POSIX tools with
each other, then why do we bother at all to implement POSIX calls in the
most POSIXy or Linuxy way possible?  Every time you don't use the Cygwin
POSIX API in favor of a native Windows call, you're breaking compatibility
with other Cygwin tools.

That's not how it's supposed to be, as far as I'm concerned...

Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  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

Re: Promote sqlite 3.7.13-1 from test status?


On 8/16/2012 4:55 AM, Corinna Vinschen wrote:

On Aug 16 04:30, Warren Young wrote:


So, what you did with that requested change, Achim, is prevented
Cygwin svn from winning any fights over ownership of .svn/wc.db.


So what?  Don't use native Windows tools in parallel accessing the
same file.  Full stop.


I've been maintaining the Cygwin SQLite package for four years now. 
This recent wish for SQLite on Cygwin to act more Unix-like is the first 
such request I've received, and I don't remember it being an issue with 
the previous maintainer, either.


But, shortly after making the change -- because I didn't immediately see 
why it would hurt anything -- complaints started pouring in from actual 
people who've been doing what you say they shouldn't do.


So what's a package maintainer to do?  Go all WJM on them? :)

I don't see why I should break previously working behavior just out of 
purity, given that, so far, only one person ever in the entire world has 
been bothered enough by that lack of purity to ask me to change how 
SQLite is compiled.



Why should mandatory locking be better here, while it's quite naturally
using advisory locking in the entire UNIX world?


Because that's what a native Windows build of SQLite does.

(Why?  Because https://sqlite.org/faq.html#q5)

Advisory locking only works when all players cooperate.  We can't assume 
that on Windows, unless we set up an insular Cygwin ghetto.



If you think it's absolutely necessary to use some Windows
functions, what is it, and why?


The scenario is this:

Dev Fred likes to use the GUI TortoiseSVN client most of the time. 
(Fred is a little strange, but we like him anyway.)


There is no Cygwin port of TortoiseSVN, because it is a deeply 
Windows-native program, doing things like adding a shell extension to 
Windows Explorer.  There is also no Cygwin GUI SVN client we can 
recommend people use instead, and even if there were, you can imagine a 
lot of people would push back, given the consequent requirement for X11.


On occasion, Fred runs into a situation where the GUI can't do a given 
task, or at least can't do it as well as you can from the command line. 
 What are Fred's options?


Option 1: Download the native Windows Subversion port.  Sensible, but it 
means you have to use a crippled shell.


Option 2: Install Cygwin and add the svn package, so you have a 
reasonable command line environment.


Why should Option 2 result in incorrect behavior, when the correct fix 
is known and -- much more important -- already implemented upstream?


Maybe you didn't realize that last, Corinna: Cygwin SQLite is built 
pretty much stock OOTB.  There's just one minor patch I make, which 
replaces a deprecated Cygwin 1.5 DLL call with its v1.7 replacement. 
Aside from ifdefs and such, it's about as stock a build as you could 
wish.  It's not like I'm patching a bunch of Windowsisms into the 
upstream source purely for Cygwin's sake.


Upstream's already made the call.

--
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: Question about UAC and bash/cygwin

On Aug 16 07:06, Lord Laraby wrote:
>  My, major emphasis is recognizing in the Cygwin dll
> or startup code somewhere) that the user has full Administrator rights
> and simply replacing his normal UID with 0 (or that of whomever root
> seems to be by /etc/passwd). Internally (at cygwin.dll level) he/she
> is still the same user, but the desired effects would be that bash and
> others might change his prompt to '#' and that scripts can check for
> admin rights and files he/she created would become owned by UID 0 (or
> the Administrators group).

What is it good for to have uid 0?  You want to know if you have admin
rights, so why don't you simply check for the admin group in the
supplementary group list?

Here's what I do in my tcsh ~/.cshrc profile to set the prompt:

  id -G | egrep -q '\<544\>' && set prompt = '#  || set prompt = '\$ '


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  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

Re: Question about UAC and bash/cygwin

Hi Corinna,

On Thu, Aug 16, 2012 Corinna Vinschen wrote:
> On Aug 16 03:39, Lord Laraby wrote:
>> I wouldn't need *all* of her knowledge of course. Just a small amount
>> would improve my understanding immensely.
>>
>> > Probably the key point that you're stumbling over is the fact that
>> > when you're elevating your user's privileges, you're not changing
>> > from that user to 'root' but rather just enabling privileges the user
>> > is allowed to use.  'whoami' will not change.
>>
>> So then, privilege elevation would be the closest analogy (for WIndows
>> 7 etc.). After all, there is no *real* user named root on 99.9% of
>> boxes out there. An administrator gets the power to become root for a
>> time. Same with UAC, etc.
>>
>> So, you see where I'm coming from with my thinking, an Administrator
>> is adble to become Windows version of root. Same as on Linux. It's not
>> not really possible using cygwin.
>
> That has nothing to do with Cygwin.  It's a restriction of the
> CreateProcess system call.  If you want to elevate, you have to elevate
> the first process in the process chain, usually mintty.  All child
> processes will be elevated as well.
>
>
> Corinna

I know it's not a Cygwin possibility to 'escacalate' using
CreateProcess, as ShellExecute seems to be the primary (only?) way to
accomplish this. My, major emphasis is recognizing in the Cygwin dll
or startup code somewhere) that the user has full Administrator rights
and simply replacing his normal UID with 0 (or that of whomever root
seems to be by /etc/passwd). Internally (at cygwin.dll level) he/she
is still the same user, but the desired effects would be that bash and
others might change his prompt to '#' and that scripts can check for
admin rights and files he/she created would become owned by UID 0 (or
the Administrators group). In other words, by simple book-keeping
record that the user is running "seuid root". At a later time, if they
use drop-privileges (sp?) remove that setting.

It seems to my limited testing that that I can simply do 'bash
--login' as an elevated cmd prompt and keep my effective permissions.
In other words, while they can't be gained through CreateProcess, they
are not removed normally either,

Does this idea seem useless to people? Does anyone agree it would be
more unixy? The question is what changes are would be involved? I'm
willing to install the needed tools and source to investigate and see
if it's up my alley. Or help in any way I can if it gets any
concensus.

~~
Thanks,

LL

--
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: Promote sqlite 3.7.13-1 from test status?

On Aug 16 04:30, Warren Young wrote:
> On 8/16/2012 2:50 AM, Corinna Vinschen wrote:
> >On Aug 16 07:41, Achim Gratz wrote:
> >>there's a race
> >>somewhere between calls from the Cygwin DLL and Windows file locking 
> >>functions.
> >
> >Cygwin does not use Windows mandatory locking.  The locking is entirely
> >implemented within the Cygwin DLL and is only advisory, as is befitting
> >for a POSIX envionment.
> 
> Interesting.  I never knew that.  I'd assumed that since Cygwin
> occasionally gets tangled up with Windows mandatory locking (e.g.
> in-use DLL replacement) that it was playing by those rules all the
> time.
> 
> >If you try to use the same file with a
> >non-Cygwin tool using Windows locking in parallel with a Cygwin tool,
> >you will get into trouble.  The mandatory Windows locking will always
> >win and the Cygwin tool will fail.
> 
> I think that nails the problem.
> 
> SQLite has a lot of Windows and Cygwin specific code in it, and in
> large part, it treats Cygwin as "Windows", including use of the
> Win32 API LockFile().  (See osLockFile() and winLock*() in
> sqlite3.c.)

*shudder*

> When you force it to build in "Unix mode", all that code gets
> ifdef'd out, replaced by an entirely different set of OS-specific
> I/O wrappers, such as unixLock().

That sounds good to me.

> So, what you did with that requested change, Achim, is prevented
> Cygwin svn from winning any fights over ownership of .svn/wc.db.

So what?  Don't use native Windows tools in parallel accessing the
same file.  Full stop.

> This could have happened to anything built against Cygwin SQLite,
> where there is also another native Windows program trying to access
> the same DB file.  The only Subversion-specific thing about this
> problem was how Subversion was coded to react when it happened.
> Another program might not say "disk I/O error," but would somehow
> fail nevertheless.
> 
> Reverting this change put Cygwin SQLite based programs back on an
> even footing with native SQLite based programs.
> 
> I gotta say, I'm not wild about the way SQLite treats Cygwin as
> Windows, bypassing the POSIX APIs so often.  Yet, you can see the
> logic, at least in the case of file locking.  Mandatory file locking
> is a very good thing in the case of SQLite.

Why should mandatory locking be better here, while it's quite naturally
using advisory locking in the entire UNIX world?

To put it another way:  A native Windows SQLight can do whatever it
wants, I don't care.  But a Cygwin SQLight should use POSIX functions
in the first place and, as such, use POSIX advisory file locking
functions and no Windows functions at all, if not absolutely necessary.

And this:  If you think it's absolutely necessary to use some Windows
functions, what is it, and why?


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  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

Re: Promote sqlite 3.7.13-1 from test status?


On 8/16/2012 2:50 AM, Corinna Vinschen wrote:

On Aug 16 07:41, Achim Gratz wrote:

there's a race
somewhere between calls from the Cygwin DLL and Windows file locking functions.


Cygwin does not use Windows mandatory locking.  The locking is entirely
implemented within the Cygwin DLL and is only advisory, as is befitting
for a POSIX envionment.


Interesting.  I never knew that.  I'd assumed that since Cygwin 
occasionally gets tangled up with Windows mandatory locking (e.g. in-use 
DLL replacement) that it was playing by those rules all the time.



If you try to use the same file with a
non-Cygwin tool using Windows locking in parallel with a Cygwin tool,
you will get into trouble.  The mandatory Windows locking will always
win and the Cygwin tool will fail.


I think that nails the problem.

SQLite has a lot of Windows and Cygwin specific code in it, and in large 
part, it treats Cygwin as "Windows", including use of the Win32 API 
LockFile().  (See osLockFile() and winLock*() in sqlite3.c.)


When you force it to build in "Unix mode", all that code gets ifdef'd 
out, replaced by an entirely different set of OS-specific I/O wrappers, 
such as unixLock().


So, what you did with that requested change, Achim, is prevented Cygwin 
svn from winning any fights over ownership of .svn/wc.db.


This could have happened to anything built against Cygwin SQLite, where 
there is also another native Windows program trying to access the same 
DB file.  The only Subversion-specific thing about this problem was how 
Subversion was coded to react when it happened.  Another program might 
not say "disk I/O error," but would somehow fail nevertheless.


Reverting this change put Cygwin SQLite based programs back on an even 
footing with native SQLite based programs.


I gotta say, I'm not wild about the way SQLite treats Cygwin as Windows, 
bypassing the POSIX APIs so often.  Yet, you can see the logic, at least 
in the case of file locking.  Mandatory file locking is a very good 
thing in the case of SQLite.


Anyway, I'm going to update my RFU request to promote 3.7.13-1 to curr.

Thanks all for the responses.  It's helped clear things up for me.

--
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 service needs to be restarted after every boot

2012-08-16 Thread Andrey Repin

Greetings, Jörg Gerlach!

>> Do you have proper dependency map for a service?
>> I.e. it should depends on TCPIP at least.

> Yes, in the properties of the "CYGWIN sshd" service in the Windows 
> Service Manager is a dependency for TCP/IP-Protocol driver.

> But, I'm not sure if you mean that.

I did mean that, and now, that you confirmed it, the situation slowly driving
into the land of BLODA.
Do you have custom firewall/AV with TCP/IP filtering capabilities installed?


--
WBR,
Andrey Repin (anrdae...@freemail.ru) 16.08.2012, <13:04>

Sorry for my terrible english...

Re: Question about UAC and bash/cygwin

On Aug 16 03:39, Lord Laraby wrote:
> Larry Hall (Cygwin) wrote:
> > On 8/15/2012 5:39 AM, Lord Laraby wrote:
> >
> >> Sorry if the questions are a bit too numerous. I wish I could just
> >> siphon knowledge from Corinna's brain.:)
> >
> > Then that would leave her with none!
> 
> I wouldn't need *all* of her knowledge of course. Just a small amount
> would improve my understanding immensely.
> 
> >
> > Probably the key point that you're stumbling over is the fact that
> > when you're elevating your user's privileges, you're not changing
> > from that user to 'root' but rather just enabling privileges the user
> > is allowed to use.  'whoami' will not change.  This is a difference
> > between Windows and Unix/Linux security models.
> 
> I see that, of course. But it was always my assumption (a warranted
> one I expect from some of the other posts I've read) that since
> neither su, nor sudo, nor newgrp, login allows becoming root in cygwin
> - and any administrator on a linux box can use those to become root.
> So then, privilege elevation would be the closest analogy (for WIndows
> 7 etc.). After all, there is no *real* user named root on 99.9% of
> boxes out there. An administrator gets the power to become root for a
> time. Same with UAC, etc.
> 
> So0, you see where I'm coming from with my thinking, an Administrator
> is adble to become Windows version of root. Same as on Linux. It's not
> not really possible using cygwin.

That has nothing to do with Cygwin.  It's a restriction of the
CreateProcess system call.  If you want to elevate, you have to elevate
the first process in the process chain, usually mintty.  All child
processes will be elevated as well.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  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

Re: Question about UAC and bash/cygwin

On Aug 15 05:39, Lord Laraby wrote:
> Adam Dinwoodie  wrote:
> 
> > Lord Laraby wrote:
> >>I've scanned months of the mailing list archives for an answers and searched
> >>until I've run out of ideas.
> >
> > Have you taken a look through the Cygwin user's guide? In particular, I 
> > suspect
> > the section on using Windows security in Cygwin will be relevant:
> >
> > http://cygwin.com/cygwin-ug-net/ntsec.html
> 
> I did indeed. In fact,I've tried to keep that document current in my
> mind with every new cygwin.dll that comes out. It's very informative
> about *Windows* security model.
> 
> However, what I can't see in that document (or the whole users guide)
> are topics related to UAC, privilege escalation/elevation (getting
> real administrator rights when you are an administrator), and anything
> about object integrity levels. How these things are very present and a
> pain in the *** on later (modern) windows hosts. There really isn't
> anything specifically related to WIndows 7's quirks.
> 
> Also, cygserver and cygLSA are really not well explained. I know they
> are there and have to do with changing user context. I know about
> passwd -R and other means of getting good user tokens. I can figure
> the rest out by reading the code I suppose.
> 
> Where I am lost in this is simply who does cygwin recognize I'm
> elevated to true administrator? It doesn't seem to and keeps putting
> all the files and directories I create (while escalated) under my
> non-elevated account rather than under root.

I don't know what you're up to, but Cygwin doesn't recognize if
your admin because it doesn't care.  Either your user token has
the required user rights to do some action or not.

If you want to use your admin rights, just elevate the mintty
window right from the start.

It's quite simple for you to find out if you're running under
UAC control, non-elevated, or if you have all rights available:
Just call `id' and see if the administors group is in your token.

> Why must I use the
> machine administrator account for this?

You don't have to.  But maybe you're a victim of file/registry
virtualization?  I'm a bit fuzzy on the details, but it happened
to me as well once, and it took ages to find out that the file
I was looking for had been stored under the
C:\Users\username\AppData\Local\VirtualStore path.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  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

RE: Promote sqlite 3.7.13-1 from test status? (was: Updated: sqlite3-3.7.13-1)

2012-08-16 Thread Adam Dinwoodie

Warren Young wrote:
> On 8/13/2012 10:12 AM, Warren Young wrote:
>>
>> This is a *test* version which reverts the patch added to 3.7.12.1-1, which
>> caused problems with Subversion as a side effect
>
> I haven't heard peep one from either side about this release on this list.
> (For contrast, I've gotten several positive responses in my answer to the
> question about this on Stack Overflow[1].)
>
> Silence = happiness, then? :)
>
> i'm asking because it was just announced that sqlite 3.7.14 won't be
> released for another 3 weeks[2].  i'm therefore thinking of promoting my
> 3.7.13-1 package to "curr" posthaste, and having the ill-fated 3.7.12.1-1
> package dropped from the mirrors.  3.7.3-1 will remain available as "prev"
> for those three weeks.  that's assuming i go ahead and build 3.7.14-1 as the
> new "curr" package.
>
> [1] http://stackoverflow.com/questions/11007024/
> [2] https://www.sqlite.org/draft/releaselog/3_7_14.html

I misread your original email; I hadn't realized I would need to install a
test version rather than be automatically upgraded (I don't routinely review
what setup.exe installs). And I didn't re-enable TortoiseSVN's icon cache as I
somehow got the impression it would require a new subversion package too. No
idea where that came from. Mea culpa.

I've no objection to you upgrading the package, I just thought I'd point out
the reason for my silence, in case other people who might have spoken up have
made similar errors.

--
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: Promote sqlite 3.7.13-1 from test status? (was: Updated: sqlite3-3.7.13-1)

On Aug 16 07:41, Achim Gratz wrote:
> Warren Young  etr-usa.com> writes:
> > I haven't heard peep one from either side about this release on this 
> > list.  (For contrast, I've gotten several positive responses in my 
> > answer to the question about this on Stack Overflow[1].)
> 
> Sorry, I've been swamped with other stuff...
> 
> > Silence = happiness, then? :)
> 
> The original bug is back, although it behaves even more wierd than before.  
> The
> error now happens _only_ when run as normal user _and_ not under strace or 
> gdb.
> 
> $ sqlite3
> SQLite version 3.7.13 2012-06-11 02:05:22
> Enter ".help" for instructions
> Enter SQL statements terminated with a ";"
> sqlite> CREATE TEMP TABLE two (id INTEGER NOT NULL, name CHAR(64) NOT NULL );
> Error: unable to open database file
> sqlite>
> 
> Since I can't reproduce the problem in the debugger anymore, it will be
> difficult to impossible to find out what's causing this (at least for me).  
> Just
> like the problem with TortoiseSVN these are indications IMHO that there's a 
> race
> somewhere between calls from the Cygwin DLL and Windows file locking 
> functions.

Cygwin does not use Windows mandatory locking.  The locking is entirely
implemented within the Cygwin DLL and is only advisory, as is befitting
for a POSIX envionment.  If you try to use the same file with a
non-Cygwin tool using Windows locking in parallel with a Cygwin tool,
you will get into trouble.  The mandatory Windows locking will always
win and the Cygwin tool will fail.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  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

Re: Promote sqlite 3.7.13-1 from test status? (was: Updated: sqlite3-3.7.13-1)

2012-08-16 Thread Achim Gratz

Warren Young  etr-usa.com> writes:
> I haven't heard peep one from either side about this release on this 
> list.  (For contrast, I've gotten several positive responses in my 
> answer to the question about this on Stack Overflow[1].)

Sorry, I've been swamped with other stuff...

> Silence = happiness, then? :)

The original bug is back, although it behaves even more wierd than before.  The
error now happens _only_ when run as normal user _and_ not under strace or gdb.

$ sqlite3
SQLite version 3.7.13 2012-06-11 02:05:22
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> CREATE TEMP TABLE two (id INTEGER NOT NULL, name CHAR(64) NOT NULL );
Error: unable to open database file
sqlite>

Since I can't reproduce the problem in the debugger anymore, it will be
difficult to impossible to find out what's causing this (at least for me).  Just
like the problem with TortoiseSVN these are indications IMHO that there's a race
somewhere between calls from the Cygwin DLL and Windows file locking functions.
 I can't rule out BLODA either.

So please go ahead and make this version current as it seems to cause less
problems given the widespread use of TortoiseSVN.  I'll see to either run the
failing application with elevated privileges or install a local patch to 
sqlite3.

Thanks for your patience on that matter.

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: Question about UAC and bash/cygwin