Return-Path: Delivered-To: apmail-apr-dev-archive@www.apache.org Received: (qmail 85487 invoked from network); 27 Aug 2004 16:20:04 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 27 Aug 2004 16:20:04 -0000 Received: (qmail 10292 invoked by uid 500); 27 Aug 2004 16:20:02 -0000 Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 10261 invoked by uid 500); 27 Aug 2004 16:20:02 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 10248 invoked by uid 99); 27 Aug 2004 16:20:01 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=RCVD_BY_IP,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Message-ID: Date: Fri, 27 Aug 2004 12:19:57 -0400 From: Jeff Trawick Reply-To: Jeff Trawick To: dev@apr.apache.org Subject: Re: [PATCH] set process attribute uid (WAS: [PATCH] WIN32 CreateProcessAsUser) In-Reply-To: <412F1437.5040508@apache.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <412EF119.8090503@apache.org> <412F1437.5040508@apache.org> X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N On Fri, 27 Aug 2004 13:00:07 +0200, Mladen Turk wrote: > Jeff Trawick wrote: > > >>The win version now makes sure that the calling tread does > >>not remain under impersonated user if something goes wrong. > > > > > > it seems very uncool for apr_procattr_FOO_set to modify any > > characteristics of the calling thread/process... is that happening on > > Win32? there's quite a bit of interesting logic in > > apr_procattr_user_set for Win32 > > > > That's the only way AFAICT to enable the 'RunAs'. > The calling thread is switching to a different account only to call > the single API function and then reverts. Other threads are not > affected, even if this is a main thread. okay, just me being ignorant; sorry > >>+APR_DECLARE(apr_status_t) apr_procattr_user_set(apr_procattr_t *attr, > >>+ const char *username, > >>+ const char *password); > > > > > > maybe this should allow specifying a group too, in case on Unix you > > don't want to require that the identity change to the default group of > > the specified user? > > > > OK. Any suggestons for the name of the second param? > Perhaps grp_or_pwd? I was thinking along the lines of a third parameter instead of overloading the second parameter. Any comments from the crowd on that choice?