This is the mail archive of the
cygwin-developers@cygwin.com
mailing list for the Cygwin project.
Re: Problems on accessing Windows network resources
- From: Corinna Vinschen <vinschen at redhat dot com>
- To: cygwin-developers at cygwin dot com
- Date: Tue, 10 Jun 2003 17:50:55 +0200
- Subject: Re: Problems on accessing Windows network resources
- References: <3EE5F5DB.8321E4@ieee.org>
- Reply-to: cygwin-developers at cygwin dot com
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.