Question about UAC and bash/cygwin

Question about UAC and bash/cygwin

[Lord Laraby]

Hi Folks,

I've scanned months of the mailing list archives for an answers and
searched until I've run out of ideas.

What I want to figure out is this. When I run bash --login -i in an
elevated command prompt, or I use "elevate bash --login -i" or any
other variation, I don't get any sign of being root or having
privileges. But, I can invoke privileged operations and use chmod,
chown, etc. on files and read, write,delete in Administrator only
directories from bash. These are places you can only change in a
raised privilege state.

My /etc/passwd and /etc/group have been automatically created and
updated to have user "root" connected to the S-1-5-32-544 sid as I
think I saw in one of the guides. My local administrator account has
the username "admin".

Problems

1) Example, "id" still shows my normal userid and default group of
'"none" even though I am a member of root's (Administrators) group.
None of the scripts that check for administrator level seem to work.
Am i doing it wrong?

2) I can't ssh into the box as "root" because there is no group
password in Windows 7. Should there be a way to assign own?

3) If I use the local administrators account, none of the files or
directories has "root" as user or group. But shouldn't they?

4) There is no newgrp command so I can't join any of my other assigned
groups. So, "umask" doesn't do as I want. If there a better way to
change to the root group?

5) When I ran sshd-host-config I get a slew of warnings about not
being able to do that (on both .\Administrator and on elevated normal
login). However, the service is created and the users cyg_server and
sshd are as well with the proper groups and privileges. Howver, it
fails to set the owner or access rights on /etc/ssh* or /var/log/sshd
or /var/log/lastlog. What is the proper way to have done this on
WIndows 7 Ultimate Edition 64-bit Service Pack I?

6) Cygwin is a great package and works better than SFU/SUA which I
also have installed. Is there any way I can help make the security
stuff more unixy?

Thanks in advance for any answers or replies.

-- 
Lord Laraby

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

[Lord Laraby]

Okay, some of this has been covered here:
http://www.cygwin.com/ml/cygwin/2008-10/msg00370.html

I'm still reading more and doing more detective work.

> --
> Lord Laraby

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

[Adam Dinwoodie]

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

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

[Lord Laraby]

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. Why must I use the
machine administrator account for this? I had wanted to leave that
special completely disabled, but it seems I'm not allowed to. Also,
when installing or updating, it seems I must use the machine
administrator account for setup.exe as well? Who owns the installed
files, otherwise? Not who I'd think.

Sorry if the questions are a bit too numerous. I wish I could just
siphon knowledge from Corinna's brain. :)

--
Lord Laraby

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

[Larry Hall (Cygwin)]

On 8/15/2012 5:39 AM, Lord Laraby wrote:

<snip>

> 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!

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.

-- 
Larry

_____________________________________________________________________

A: Yes.
 > Q: Are you sure?
 >> A: Because it reverses the logical flow of conversation.
 >>> Q: Why is top posting annoying in email?

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

Re: Question about UAC and bash/cygwin

[Lord Laraby]

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.

> --
> Larry

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

[Corinna Vinschen]

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

[Corinna Vinschen]

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

[Lord Laraby]

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

[Corinna Vinschen]

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

[Lord Laraby]

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

[Lord Laraby]

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

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

[Kurt Franke]

Lord Laraby <lord.laraby <at> 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 <at> Master-PC ~
> $ cd /etc/at-spi2/
> 
> master <at> 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 <at> Master-PC /etc/at-spi2
> $ ls -l
> total 4
> -rw-r--r-- 1 admin none 1335 May 15 03:27 accessibility.conf
> 
> master <at> 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 <at> Master-PC ~
> $ id
> uid=1001(master) gid=0(root)
> groups=0(root),545(users),1007(hlplibrupdaters),1000(homegrp),513(none)
> 
> master <at> Master-PC ~
> $ cd /etc/at-spi2/
> 
> master <at> Master-PC /etc/at-spi2
> $ ls -l
> total 4
> -rw-r--r-- 1 admin none 1335 May 15 03:27 accessibility.conf
> 
> master <at> Master-PC /etc/at-spi2
> $ mv accessibility.conf accessibility.conf.sav
> 
> ^^^ No error and successfully used admin provileges...
> 
> master <at> Master-PC /etc/at-spi2
> $ mv accessibility.conf.sav accessibility.conf
> 
> ^^^ Again
> 
> master <at> Master-PC /etc/at-spi2
> $ ls -l
> total 4
> -rw-r--r-- 1 admin none 1335 May 15 03:27 accessibility.conf
> 
> master <at> 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 <at> 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 <stdio.h>
#define _WIN32_WINNT 0x0500
#include <windows.h>

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_version -ge 5 ]
then
  # executable calling CheckTokenMembership for the Admin group
  # which will also get correct result for non-elevated
  # Admin sessions when running under vista 
  # first check if there
  type CheckTokenMembership-Admin >/dev/null 2>&1
  found_CheckTokenMembership_Admin=$?
  if [ $found_CheckTokenMembership_Admin -eq 0 ]
  then
    CheckTokenMembership-Admin
    exit $?
  fi
  # if CheckTokenMembership-Admin is not found then just
  # use the standard test as for other Windows Versions
fi

hasAdminGroup=0
group_ids=`id -G`
for i in `grep ':S-1-5-32-544:' /etc/group | cut -d: -f3`
do
  for k in $group_ids
  do
    [ $k = $i ] && hasAdminGroup=$((hasAdminGroup+1))
  done
done

if [ $hasAdminGroup -gt 0 ]
then
  if [ $is_NT -gt 0 -a $NT_main_version -ge 6 ]
  then
    # cannot really determine if running with admin privileges
    # in windows vista when only checking the group membership
    # exit with another value to indicate this
    exit 2
  else
    exit 0
  fi
else
  exit 1
fi


================= --- isAdmin =================



regards

kf











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

[Corinna Vinschen]

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

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

[Lord Laraby]

On Thu, Aug 16, 2012 at 3:00 PM, Christian Franke
<Christian.Franke@t-online.de> 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: Question about UAC and bash/cygwin

[Lord Laraby]

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

[Lord Laraby]

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

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

[Christopher Faylor]

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