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
