This is the mail archive of the cygwin@cygwin.com 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: security.cc: bug report, question and suggestion


On Thu, Jan 24, 2002 at 04:17:47PM -0500, Pierre A. Humblet wrote:
> Corinna Vinschen wrote:
> 
> > Sorry but I don't see what you've tested.  The patch should address
> > your problem with the access rights of the impersonation token.
> 
> The attachment has a printout of the security info of the impersonation
> token. Its DACL is not set the way you intend to have it, in fact
> things seem to be as before your changes. 
> If you want I can send you my token printing program.

I have my own token print application which I changed to print
the security descriptor (SD) of the token additionally.  What I found
was:

- The owner returned by TOKEN_OWNER is the same as the owner of
  the token's SD.

- The group returned by TOKEN_GROUP is the same as the group of
  the token's SD.

- The DACL returned by TOKEN_DEFAULT_DACL is the same as the DACL
  of the token's SD.

So, actually there's no need to distinguish between the token and
it's SD.

Sorry, Pierre, but I'm somewhat confused.  I must admit that I
don't understand your problem with the registry access in that
light.  I read your first mail in this thread again but I'm pretty
sure I'm missing some information.

The registry you're trying to access, is that a key below HKCU or
HKLM?  In which situation does the application try to read the
registry key, before or after the successful setuid() call?  Does
the application even try to read the registry key after setuid()
or does a exec'd child process try to do that?

> The real problem is that following setuid(), the ACL (not default
> ACL) of the impersonation token (which is inherited from the
> default ACL of the process token) makes the impersonation
> token non-accessible by its user
> (normally the user has full access to its token,
> and it seems that setuid() should preserve that).

I see now that I don't know of which user you're talking here,
the user who's *creating* the token or the user who's going to
be *impersonated* by the token?

Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin@cygwin.com
Red Hat, Inc.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


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