* Different commands give different groups
@ 2011-10-01 3:49 gsingh93
2011-10-01 13:55 ` Eric Blake
0 siblings, 1 reply; 3+ messages in thread
From: gsingh93 @ 2011-10-01 3:49 UTC (permalink / raw)
To: cygwin
Why do these two commands give different groups? It's the same user.
Gulshan@GSJK-PC /etc
$ id Gulshan
uid=1000(Gulshan) gid=545(Users) groups=545(Users),0(root)
Gulshan@GSJK-PC /etc
$ id
uid=1000(Gulshan) gid=545(Users) groups=545(Users),513(None)
Furthermore, the commands mkgroup and mkpasswd give the orginial states of
their corresponding files instead of what I changed them to. Why is that?
--
View this message in context: http://old.nabble.com/Different-commands-give-different-groups-tp32572751p32572751.html
Sent from the Cygwin list mailing list archive at Nabble.com.
--
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Different commands give different groups
2011-10-01 3:49 Different commands give different groups gsingh93
@ 2011-10-01 13:55 ` Eric Blake
2011-10-02 2:37 ` gsingh93
0 siblings, 1 reply; 3+ messages in thread
From: Eric Blake @ 2011-10-01 13:55 UTC (permalink / raw)
To: cygwin
On 09/30/2011 09:49 PM, gsingh93 wrote:
>
> Why do these two commands give different groups? It's the same user.
Because the effective gid set for the existing process differs from the
recorded groups in /etc/groups - most likely, you've changed /etc/groups
but haven't logged out and back in to start a new process hierarchy that
uses the new groups.
>
> Gulshan@GSJK-PC /etc
> $ id Gulshan
> uid=1000(Gulshan) gid=545(Users) groups=545(Users),0(root)
That's what the groups will be if a new process is started for Gulshan.
>
> Gulshan@GSJK-PC /etc
> $ id
> uid=1000(Gulshan) gid=545(Users) groups=545(Users),513(None)
Whereas that's what the groups are now for the current process.
This aspect of your situation is not cygwin-specific, the same behavior
can be observed in other OSs when you change the user database after a
particular user already has a process started.
>
> Furthermore, the commands mkgroup and mkpasswd give the orginial states of
> their corresponding files instead of what I changed them to. Why is that?
This part is cygwin-specific - and the answer is that mkgroup and
mkpasswd are querying Window's database of user information, not /etc
(so that you can then populate /etc with information that matches the
Window's database). Windows doesn't care what you put in /etc, so the
amount of changes you can make in those files that still have a
worthwhile visible effect to cygwin processes is a bit limited.
--
Eric Blake eblake@redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
--
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Different commands give different groups
2011-10-01 13:55 ` Eric Blake
@ 2011-10-02 2:37 ` gsingh93
0 siblings, 0 replies; 3+ messages in thread
From: gsingh93 @ 2011-10-02 2:37 UTC (permalink / raw)
To: cygwin
That makes sense, but I've completely restarted my computer and yet it still
shows the old groups. So a new process that uses the new groups hasn't
started. Any idea why?
eblake wrote:
>
> On 09/30/2011 09:49 PM, gsingh93 wrote:
>>
>> Why do these two commands give different groups? It's the same user.
>
> Because the effective gid set for the existing process differs from the
> recorded groups in /etc/groups - most likely, you've changed /etc/groups
> but haven't logged out and back in to start a new process hierarchy that
> uses the new groups.
>
>>
>> Gulshan@GSJK-PC /etc
>> $ id Gulshan
>> uid=1000(Gulshan) gid=545(Users) groups=545(Users),0(root)
>
> That's what the groups will be if a new process is started for Gulshan.
>
>>
>> Gulshan@GSJK-PC /etc
>> $ id
>> uid=1000(Gulshan) gid=545(Users) groups=545(Users),513(None)
>
> Whereas that's what the groups are now for the current process.
>
> This aspect of your situation is not cygwin-specific, the same behavior
> can be observed in other OSs when you change the user database after a
> particular user already has a process started.
>
>>
>> Furthermore, the commands mkgroup and mkpasswd give the orginial states
>> of
>> their corresponding files instead of what I changed them to. Why is that?
>
> This part is cygwin-specific - and the answer is that mkgroup and
> mkpasswd are querying Window's database of user information, not /etc
> (so that you can then populate /etc with information that matches the
> Window's database). Windows doesn't care what you put in /etc, so the
> amount of changes you can make in those files that still have a
> worthwhile visible effect to cygwin processes is a bit limited.
>
> --
> Eric Blake eblake@redhat.com +1-801-349-2682
> Libvirt virtualization library http://libvirt.org
>
> --
> 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
>
>
>
--
View this message in context: http://old.nabble.com/Different-commands-give-different-groups-tp32572751p32576391.html
Sent from the Cygwin list mailing list archive at Nabble.com.
--
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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2011-10-02 2:37 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-10-01 3:49 Different commands give different groups gsingh93
2011-10-01 13:55 ` Eric Blake
2011-10-02 2:37 ` gsingh93
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).