This is the mail archive of the cygwin-developers@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: Problems on accessing Windows network resources


On Tue, Jun 10, 2003 at 11:14:35AM -0400, Pierre A. Humblet wrote:
> The cleanest way to fixup the problem in cygwin is to
> keep the token from the cygwin_logon_user even
> when creating an internal token, and to go back to
> it automatically when needed.
> It's easy, I can probably do that this evening.

How do you determine that it's needed?

> Another way is to assume that when we setuid to 18,
> we also implicitly setgid to 544. That's more risky
> because some installations (possibly the 2003 machines) 
> may use another SID than SYSTEM to run their daemons.

I'm wondering if we can't simply make the assumption, that when the
application calls seteuid(orig_uid) just triggers a RevertToSelf()
and nothing else.  I don't know a case where the application reverts
to orig_uid to keep the group rights.  Do you know one?

And the other way around, if the application provides a token with
cygwin_set_impersonation_token(), then that means, IMHO:

- The application calls setegid() with gid != token_primary_group_gid:

	trigger create_token in a later call to seteuid()

- The application calls setegid() with gid == token_primary_group_gid:

	Use token from cygwin_set_impersonation_token().

- The application doesn't call setegid():

	Ditto.

Case 3 is the interesting one.

Corinna

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


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