This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: bug report, question and suggestion

At 12:33 AM 1/20/02 +0100, you wrote:
>On Sat, Jan 19, 2002 at 04:52:18PM -0500, Pierre A. Humblet wrote:

>The problem is that in contrast to POSIX the PrimaryGroup is
>restricted to the Groups already listed in the access token
>of the process.  So it will fail if the primary group is set
>only for a later impersonation.  But that shouldn't matter
>then, IMO.

OK, that's what I meant in the first paragraph. I had in mind the 
case where the gid is not in the existing Groups. It will become
effective at the next setuid().

>I'm not quite sure if I understand.  If the setgid() is made
>while a impersonation is active, the setgid() should affect
>the impersonation token.  

No, no, it changes the process token.
 if (!OpenProcessToken (GetCurrentProcess (),

>> Wouldn't it be safer to always rely on myself->gid to set ACLs
>> and only use the PrimaryToken to verify if an existing token 
>> can be reused?
>Good question.  However, I don't think it's unsafe to change
>the primary group.  If it was successful, further securable
>objects are created using the correct primary group.  If it
>wasn't successful, nothing has changed, nothing got worse.

Yes, but it's undetermined (except if the caller really knows
the Groups), which isn't so good. By using myself->gid you could 
change the primary group on securable objects to what it should be.
BTW, does the primary group need to be in the Groups there too?


Unsubscribe info:
Bug reporting:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]