This is the mail archive of the
mailing list for the Cygwin project.
Re: security.cc: 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
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. syscalls.cc:
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: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html