will bash honor the suid bit or not?

will bash honor the suid bit or not?

[Richard Troy]

Hi All,

I've got an application I'm trying to port from Unix to cygwin on Windows
NT/2000 using NTFS.

The application consists of an executable and a few configuration files.
To work correctly, the executable and configuration files need to be owned
by any ole user which is _not_ the user who wishes to run the application.
Root/Administrator privileges are _not_ required, or desireable. The
config files and executable are then secured from the user being able to
change them, or view the configuration files. The suid bit of the
executable is set in the file system. When the user runs the program,
bash, or whatever shell, should then note the suid bit and run the program
in the user context of the file owner, not the user who executes the
program. The application thereby has access to the config files that the
user does not ordinarily have.

The program does not call, and does not need to call setuid(), nor any
other flavor of such a call.

The program works just fine on every Unix and Linux system upon which it
has so far been tried. Now for Windows NT/2000! In setting it up and
testing, I found that it runs properly for the user who owns the
executable and configuration files. However, if another user tries to run
it, it fails.

In reading up, there's talk of the cygwin dll having a setuid() function,
so I don't understand why the cygwin bash shell doesn't honor the setuid
bit. I also observe that the file system _appears_ to honor the concept of
the setuid bit. That is to say, you can $ chmod u+s <file>, and
$ls -l <file> also shows the bit being set (or cleared as the case may
be). ...SO... If the cygwin bash doesn't honor the bit, why bother having
it available? (I didn't see this on the "to do" list.)

It occurrs to me that there's a section in the User's Guide, which I
didn't quite understand, that talks about "special permissions." In
particular, it states:

   "NT uses so called `access tokens' to identify a user and it's
   permissions. To switch the user context the application has to request
   such an `access token'. This is typically done by calling the NT API
   function LogonUser. The access token is returned and either used in
   ImpersonateLoggedOnUser to change user context of the current process
   or in CreateProcessAsUser to change user context of a spawned child
   process. An important restriction is that the application
   using LogonUser must have special permissions"

How to set these special permissions is not discussed, and it merely
begins describing how to write a setuid call - or, rather, replace it?
...Either way, it's my (barely educated) view that BASH should recognize
that the suid bit is set for the about-to-be-executed image and should
place the call to CreateProcessAsUser on our behalf... This would avoid
-any- coding changes whatsoever. It would be _very_ useful, too!

So... Do I merely have to set special permissions on the application
program somehow? If so, pray-tell how? Or, is there no solution today? If
there's no solution, since I _have_ to solve this, should I take it upon
myself to contribute a tiny piece of code that implements this that could
later be rolled into the cygwin-bash? (Please note that I don't really
feel competent to write such code! I have _never_ written _any_ "Windows"
application code!)

Inquiring minds - and creative and demanding hackers - need to know!

...Thanks in advance for your time!

Richard

-- 
Richard Troy, Chief Scientist
Science Tools Corporation
rtroy@ScienceTools.com, 510-567-9957, http://ScienceTools.com/


--
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/

Re: will bash honor the suid bit or not?

[Larry Hall (RFK Partners, Inc)]

At 09:56 PM 4/17/2002, Richard Troy wrote:

>Hi All,
>
>I've got an application I'm trying to port from Unix to cygwin on Windows
>NT/2000 using NTFS.
>
>The application consists of an executable and a few configuration files.
>To work correctly, the executable and configuration files need to be owned
>by any ole user which is _not_ the user who wishes to run the application.
>Root/Administrator privileges are _not_ required, or desireable. The
>config files and executable are then secured from the user being able to
>change them, or view the configuration files. The suid bit of the
>executable is set in the file system. When the user runs the program,
>bash, or whatever shell, should then note the suid bit and run the program
>in the user context of the file owner, not the user who executes the
>program. The application thereby has access to the config files that the
>user does not ordinarily have.
>
>The program does not call, and does not need to call setuid(), nor any
>other flavor of such a call.
>
>The program works just fine on every Unix and Linux system upon which it
>has so far been tried. Now for Windows NT/2000! In setting it up and
>testing, I found that it runs properly for the user who owns the
>executable and configuration files. However, if another user tries to run
>it, it fails.
>
>In reading up, there's talk of the cygwin dll having a setuid() function,
>so I don't understand why the cygwin bash shell doesn't honor the setuid
>bit. I also observe that the file system _appears_ to honor the concept of
>the setuid bit. That is to say, you can $ chmod u+s <file>, and
>$ls -l <file> also shows the bit being set (or cleared as the case may
>be). ...SO... If the cygwin bash doesn't honor the bit, why bother having
>it available? (I didn't see this on the "to do" list.)
>
>It occurrs to me that there's a section in the User's Guide, which I
>didn't quite understand, that talks about "special permissions." In
>particular, it states:
>
>    "NT uses so called `access tokens' to identify a user and it's
>    permissions. To switch the user context the application has to request
>    such an `access token'. This is typically done by calling the NT API
>    function LogonUser. The access token is returned and either used in
>    ImpersonateLoggedOnUser to change user context of the current process
>    or in CreateProcessAsUser to change user context of a spawned child
>    process. An important restriction is that the application
>    using LogonUser must have special permissions"
>
>How to set these special permissions is not discussed, and it merely
>begins describing how to write a setuid call - or, rather, replace it?
>...Either way, it's my (barely educated) view that BASH should recognize
>that the suid bit is set for the about-to-be-executed image and should
>place the call to CreateProcessAsUser on our behalf... This would avoid
>-any- coding changes whatsoever. It would be _very_ useful, too!
>
>So... Do I merely have to set special permissions on the application
>program somehow? If so, pray-tell how? Or, is there no solution today? If
>there's no solution, since I _have_ to solve this, should I take it upon
>myself to contribute a tiny piece of code that implements this that could
>later be rolled into the cygwin-bash? (Please note that I don't really
>feel competent to write such code! I have _never_ written _any_ "Windows"
>application code!)
>
>Inquiring minds - and creative and demanding hackers - need to know!
>
>...Thanks in advance for your time!


You've hit on the key aspect of the issue that's keeping you from doing what
you want to do.  Specifically, you quoted the important paragraph from the 
User's Guide.  It sounds like you may have missed the other important tidbits 
that are sprinkled through the email archives and various READMEs in 
/usr/doc/Cygwin.  The first thing you need is to set 'ntsec' in your CYGWIN 
environment variable.  You may already have this but you didn't mention it so 
I thought I'd better state it for completeness.  This needs to be set before 
cygwin1.dll is loaded.  Now, to the bigger issue.  NT permissions don't give 
user's the permissions by default to change user context.  So, while the good 
news is that it should be possible to get things to work as you need them, 
the bad news is that you won't be able to do it without making changes to the 
user's rights.  These rights are:

"Act as part of the operating system"
"Replace process level token"
"Increase quotas"

These rights, plus "Logon as a service", are given by default to the 
SYSTEM user but no others.  The reason is that these are very powerful 
permissions.  To give them to any user other than SYSTEM makes the system
very insecure.  So, while this should make things work for you, you'll be
stuck with having to add these rights for any user you wish to have run 
the program and you'll be compromising security along the way.  If this is
OK for your purposes, then I think you have your answer.  Given that the 
process you describe seeks to limit the user's ability to make modifications
(at least to the files used by your program), I'm guessing the need to add
these rights to all users of the program is going to be defeating the purpose.
I could be wrong.

The rights I listed above are from /usr/doc/Cygwin/openssh*.REEADME and
/usr/doc/Cygwin/inetutils*.README.  There's some discussion there about other
requirements and concerns as well, although much of it is in the context of 
services, which can change user contexts without making the system insecure.

Obviously, I'm only applying what I know of NT's restrictions on changing 
user contexts (thanks Corinna! :-) ) to the description of the requirements
you gave for your application and drawing conclusions based on that.  It's
possible that I've missed some key aspect of NT rights management or your
application needs that would allow you to get things working with no 
additional changes to your program.  If changes are needed and they can 
be accomplished outside of your application, I believe that the first target
for the changes should be the Cygwin DLL.  If that's not possible, then 
perhaps a Cygwin specific change to bash is appropriate.  I would submit,
however, that a similar change would need to be made for other shells to 
be robust.  Of course, the robustness concept breaks down when one considers
shells that aren't provided by Cygwin so I'm dubious about this approach in
general.

Good luck,


Larry Hall                              lhall@rfk.com
RFK Partners, Inc.                      http://www.rfk.com
838 Washington Street                   (508) 893-9779 - RFK Office
Holliston, MA 01746                     (508) 893-9889 - FAX


--
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/

Re: will bash honor the suid bit or not?

[Richard Troy]

Thank you for your reply, Larry.

You're right when you say that the requirement to give these permissions
would defeat the whole purpose. In short, the purpose of the application
itself is security-related. The information contained in the config. files
is sensitive. The user needs to have the benefit of the data - through
action of the program - but should not have access to the data itself.
Giving out extensive privileges is exactly contray to this purpose.

And you were right to guess that I already set ntsec in CYGWIN - it was my
first move. That, and to put the definition in the systems env. vars, so
other users who log in without Administrator privilege can't change it.

I am apparently ignorant of how to handle a case like this on NT/2000, nor
do I even know where to look. This problem must be solved for many uses
already. I would think that a great many services have this same problem.
It's an exceptionally common need to have a non-privileged user run a
program and get privileged results. ...I'm a skilled, experienced
programmer, but am _completely_ ignorant of the NT/2000 world - I don't
even know where to look for answers! Worse, I'm very short on time.
Yesterday, for example, I put in 19 hours of work. ...Working tired sure
doesn't help. -sigh-

From where I sit, it sure looks like this problem should be solved for the
BASH shell. Perhaps it should become a service? I dunno!

It'd be great to hear from more of you: Anyone else care to confirm
Larry's suggestion that giving privileges to users is the solution in this
case?

Thanks for your input,
Richard

-- 
Richard Troy, Chief Scientist
Science Tools Corporation
rtroy@ScienceTools.com, 510-567-9957, http://ScienceTools.com/

On Wed, 17 Apr 2002, Larry Hall (RFK Partners, Inc) wrote:

> Date: Wed, 17 Apr 2002 22:34:29 -0400
> From: "Larry Hall (RFK Partners, Inc)" <lhall@rfk.com>
> To: Richard Troy <rtroy@sciencetools.com>, cygwin@cygwin.com
> Subject: Re: will bash honor the suid bit or not?
>
> At 09:56 PM 4/17/2002, Richard Troy wrote:
>
> >Hi All,
> >
> >I've got an application I'm trying to port from Unix to cygwin on Windows
> >NT/2000 using NTFS.
> >
> >The application consists of an executable and a few configuration files.
> >To work correctly, the executable and configuration files need to be owned
> >by any ole user which is _not_ the user who wishes to run the application.
> >Root/Administrator privileges are _not_ required, or desireable. The
> >config files and executable are then secured from the user being able to
> >change them, or view the configuration files. The suid bit of the
> >executable is set in the file system. When the user runs the program,
> >bash, or whatever shell, should then note the suid bit and run the program
> >in the user context of the file owner, not the user who executes the
> >program. The application thereby has access to the config files that the
> >user does not ordinarily have.
> >
> >The program does not call, and does not need to call setuid(), nor any
> >other flavor of such a call.
> >
> >The program works just fine on every Unix and Linux system upon which it
> >has so far been tried. Now for Windows NT/2000! In setting it up and
> >testing, I found that it runs properly for the user who owns the
> >executable and configuration files. However, if another user tries to run
> >it, it fails.
> >
> >In reading up, there's talk of the cygwin dll having a setuid() function,
> >so I don't understand why the cygwin bash shell doesn't honor the setuid
> >bit. I also observe that the file system _appears_ to honor the concept of
> >the setuid bit. That is to say, you can $ chmod u+s <file>, and
> >$ls -l <file> also shows the bit being set (or cleared as the case may
> >be). ...SO... If the cygwin bash doesn't honor the bit, why bother having
> >it available? (I didn't see this on the "to do" list.)
> >
> >It occurrs to me that there's a section in the User's Guide, which I
> >didn't quite understand, that talks about "special permissions." In
> >particular, it states:
> >
> >    "NT uses so called `access tokens' to identify a user and it's
> >    permissions. To switch the user context the application has to request
> >    such an `access token'. This is typically done by calling the NT API
> >    function LogonUser. The access token is returned and either used in
> >    ImpersonateLoggedOnUser to change user context of the current process
> >    or in CreateProcessAsUser to change user context of a spawned child
> >    process. An important restriction is that the application
> >    using LogonUser must have special permissions"
> >
> >How to set these special permissions is not discussed, and it merely
> >begins describing how to write a setuid call - or, rather, replace it?
> >...Either way, it's my (barely educated) view that BASH should recognize
> >that the suid bit is set for the about-to-be-executed image and should
> >place the call to CreateProcessAsUser on our behalf... This would avoid
> >-any- coding changes whatsoever. It would be _very_ useful, too!
> >
> >So... Do I merely have to set special permissions on the application
> >program somehow? If so, pray-tell how? Or, is there no solution today? If
> >there's no solution, since I _have_ to solve this, should I take it upon
> >myself to contribute a tiny piece of code that implements this that could
> >later be rolled into the cygwin-bash? (Please note that I don't really
> >feel competent to write such code! I have _never_ written _any_ "Windows"
> >application code!)
> >
> >Inquiring minds - and creative and demanding hackers - need to know!
> >
> >...Thanks in advance for your time!
>
>
> You've hit on the key aspect of the issue that's keeping you from doing what
> you want to do.  Specifically, you quoted the important paragraph from the
> User's Guide.  It sounds like you may have missed the other important tidbits
> that are sprinkled through the email archives and various READMEs in
> /usr/doc/Cygwin.  The first thing you need is to set 'ntsec' in your CYGWIN
> environment variable.  You may already have this but you didn't mention it so
> I thought I'd better state it for completeness.  This needs to be set before
> cygwin1.dll is loaded.  Now, to the bigger issue.  NT permissions don't give
> user's the permissions by default to change user context.  So, while the good
> news is that it should be possible to get things to work as you need them,
> the bad news is that you won't be able to do it without making changes to the
> user's rights.  These rights are:
>
> "Act as part of the operating system"
> "Replace process level token"
> "Increase quotas"
>
> These rights, plus "Logon as a service", are given by default to the
> SYSTEM user but no others.  The reason is that these are very powerful
> permissions.  To give them to any user other than SYSTEM makes the system
> very insecure.  So, while this should make things work for you, you'll be
> stuck with having to add these rights for any user you wish to have run
> the program and you'll be compromising security along the way.  If this is
> OK for your purposes, then I think you have your answer.  Given that the
> process you describe seeks to limit the user's ability to make modifications
> (at least to the files used by your program), I'm guessing the need to add
> these rights to all users of the program is going to be defeating the purpose.
> I could be wrong.
>
> The rights I listed above are from /usr/doc/Cygwin/openssh*.REEADME and
> /usr/doc/Cygwin/inetutils*.README.  There's some discussion there about other
> requirements and concerns as well, although much of it is in the context of
> services, which can change user contexts without making the system insecure.
>
> Obviously, I'm only applying what I know of NT's restrictions on changing
> user contexts (thanks Corinna! :-) ) to the description of the requirements
> you gave for your application and drawing conclusions based on that.  It's
> possible that I've missed some key aspect of NT rights management or your
> application needs that would allow you to get things working with no
> additional changes to your program.  If changes are needed and they can
> be accomplished outside of your application, I believe that the first target
> for the changes should be the Cygwin DLL.  If that's not possible, then
> perhaps a Cygwin specific change to bash is appropriate.  I would submit,
> however, that a similar change would need to be made for other shells to
> be robust.  Of course, the robustness concept breaks down when one considers
> shells that aren't provided by Cygwin so I'm dubious about this approach in
> general.
>
> Good luck,
>
>
> Larry Hall                              lhall@rfk.com
> RFK Partners, Inc.                      http://www.rfk.com
> 838 Washington Street                   (508) 893-9779 - RFK Office
> Holliston, MA 01746                     (508) 893-9889 - FAX
>


--
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/

Re: will bash honor the suid bit or not?

[Sam Edge]

> And you were right to guess that I already set ntsec in CYGWIN - it was my
> first move. That, and to put the definition in the systems env. vars, so
> other users who log in without Administrator privilege can't change it.

I also set the CYGWIN environment in the "system variables" section of the NT configuration simply so that I can run Cygwin executables under any account without having to worry about it.

However, this doesn't prevent ordinary users from changing its value prior to running Cygwin programs. Open an NT command prompt (CMD.EXE), type "SET CYGWIN=" and then "bash" and you'll see.

> I am apparently ignorant of how to handle a case like this on NT/2000, nor
> do I even know where to look. This problem must be solved for many uses
> already. I would think that a great many services have this same problem.
> It's an exceptionally common need to have a non-privileged user run a
> program and get privileged results. 

The way it's normally done on NT is by installing a service - a special type of application that runs under the NT Service Manager susbsystem. (This is designed for processes that run independently of interactive users. It's used to implement the equivalent of UNIX daemon processes and other "system" facilities.)

The service runs as SYSTEM or some other priveleged account and user processes use IPC to access its facilities in a controlled manner.

> From where I sit, it sure looks like this problem should be solved for the
> BASH shell. 

Under UNIX-like systems it's not bash that modifies the UID/GID of the created process but the operating system when asked to exec() a file with the appropriate suid/sgid bit set.

Non-superuser processes can't call setXid() with an ID other than one of their own anyway. If they try, the call fails with errno == EPERM. (Otherwise any user could write a program that runs with the priveleges of any other!)

> Perhaps it should become a service? I dunno!

LOL. It's certainly not a good idea to start making major architectural changes in the shell program!

> It'd be great to hear from more of you: Anyone else care to confirm
> Larry's suggestion that giving privileges to users is the solution in this
> case?

If it's a security application then no. A better solution for NT would be to split the program into a client application and a non-Cygwin-based server service and have them communicate via whatever IPC mechanism with which you're happy. If you used TCP/IP sockets the client could remain a Cygwin application and you would be able to write a UNIX version of the server at some point too. An NT-specific solution might find RPC more appropriate though.

You could write a standard UNIX-style daemon as a Cygwin application that uses sockets and install it as an NT service using cygrunsrv but this isn't a secure solution. The Cygwin documentation tells us that all Cygwin processes have access to shared memory resources and can compromise each others integrity.

-- 
Sam Edge


--
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/

Re: will bash honor the suid bit or not?

[Corinna Vinschen]

On Wed, Apr 17, 2002 at 06:56:08PM -0700, Richard Troy wrote:
> [...]

First of all, it's not bash but the OS (here Cygwin) which would
have to care for the suid bit.

Second, the suid bit is available with ntsec on NTFS file systems
but for now it's *only* available as a flag.  It has no effect!
The implementation of suid under Win32 requires a running daemon
with special permissions (running under SYSTEM account, that is)
which can start a process under a different user account on behalf
of the calling process.  The daemon already exists but the suid
functionality isn't implemented yet.  It requires a person with
a lot of time, actually...

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/

cygwin mentors? Was: bash and the suid bit

[Richard Troy]

> First of all, it's not bash but the OS (here Cygwin) which would
> have to care for the suid bit.

-smile-

> Second, the suid bit is available with ntsec on NTFS file systems
> but for now it's *only* available as a flag.  It has no effect!

Yes! I have learned this! And I am sad because of it.

> The implementation of suid under Win32 requires a running daemon
> with special permissions (running under SYSTEM account, that is)
> which can start a process under a different user account on behalf
> of the calling process.  The daemon already exists but the suid
> functionality isn't implemented yet.  It requires a person with
> a lot of time, actually...

Yes, I was afraid of that. -frown-

Perhaps this seems a silly place to say so, but I'm very impressed with
the work I've seen in CYGWIN, and in the open community and GNU in
general. In researching this SUID problem, I spent six or eight hours
yesterday reading all the related posts from the archive, and I noticed
how there's a lot of really good work - the internals discussions have
been well written and there are a few of you, like you, Corinna, who are
outstanding contributors... And, I have been wondering how I might
contribute too, being as over- worked and as busy as I am. However, I
_really_ need this - or some solution - working in this environment, so it
seems we have a case of converging needs. I think It makes more sense for
me to help out with suid than it does for me to write a one-off.

... After thinking it over for a bit...

I'm willing to give it a go if someone can mentor me along. My
apprenticeship resume: I started hacking in '77 at the tender age of 14,
so by now I've got a lot of experience. I once wrote a complete real-time,
multi-tasking operating system by myself which is in use today controlling
pipelines and oil refineries, and I used to be one of the top VAX/VMS
internals people at DEC, so this internals experience must be of some use
here, especially since NT/W2k is based on VMS. If someone were to work
with me, point me at the juicy stuff so I don't have to hunt so much, I
can probably commit to this project. Otherwise, I'm concerned it'll take
me too long to ramp up.

Anyone want to be a mentor?

Regards,
Richard

-- 
Richard Troy, Chief Scientist
Science Tools Corporation
rtroy@ScienceTools.com, 510-567-9957, http://ScienceTools.com/




--
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/

Re: cygwin mentors? Was: bash and the suid bit

[Corinna Vinschen]

On Thu, Apr 18, 2002 at 07:19:09AM -0700, Richard Troy wrote:
> >   It requires a person with
> > a lot of time, actually...
> 
>  And, I have been wondering how I might
> contribute too, being as over- worked and as busy as I am.

Contribution is something you're doing voluntarily and just
as far as you're able to.  We all have daytime jobs which
take more or less time.  If there's energy left a few minutes
a day... go ahead and contribute.

> Anyone want to be a mentor?

Why is it so difficult to get into Cygwin?  Take the sources
try to compile and then change what you think should be changed.
Small changes first, big changes later.  And don't be offended if
a change is rejected.  That's how it worked for me back in 1998
and that's how it works today.

Oh, and take a look onto http://cygwin.com/contrib.html.

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/

Re: cygwin mentors? Was: bash and the suid bit

[Richard Troy]

> > >   It requires a person with
> > > a lot of time, actually...
> >
> >  And, I have been wondering how I might
> > contribute too, being as over- worked and as busy as I am.
>
> Contribution is something you're doing voluntarily and just
> as far as you're able to.  We all have daytime jobs which
> take more or less time.  If there's energy left a few minutes
> a day... go ahead and contribute.

Not this time, Corinna. A Contribution is a contribution, regardless of
the circumstances of its creation, I submit. I am, personally, interested
in helping, however, if it weren't for the confluence of needs, I would
not even be able to entertain the concept of helping at this time.

You may operate under the assumption that it's left-over minutes in the
day that are being applied, and you're probably right for most everyone
else.  However, that's not what I'm proposing. If I attempt this, it will
be "during my work day", which, at the present time, comprises about 5AM
to midnight every day, including weekends and most holidays - aren't
startup companies fun? -wink- ...I need this other code to run on a
Windows Box (NT/2k and later), and it's a high priority. If the best way
to get it there is to help implement suid in cygwin, then I can justify it
and both cygwin and my work benefit. Since I think my problem would be
solved if only cygwin honored the suid bit, then it may make sense.
Otherwise, I'm off to create a wholly different solution that will
probably not make use of cygwin at all, and in that case, cygwin won't
benefit.

That said, presuming I give it a go, while this is a very high priority,
it doesn't mean I can spend 100% of my time on it until it's done, though
I may spend 8 hours a day on it, perhaps. ...Anyway, this is why I'm
asking for a mentor: Help keep me focused on this problem and not get lost
on dead-ends. Remember I indicated I have no experience programming in
this environment, and it's clear enough I'm not yet fully informed of the
systems internals issues that NT+ pose. Yet some of you are. If you can
point me in the right direction, this could work. Or, you could let me
flail around, spend countless hours reading email archives only to not
find direction, spend countless more reading up on MS topics that don't
really have anything to do with what I'm trying to do - but I don't know
any better - and the project suffers and with it my work. And we both
loose - cygwin looses a potentially very helpful contribution and I loose
potentially very important hours.

Resolving this connundrum is exactly what mentorship is all about: Focus
the newcomer on the important things. If you are - someone is - up for it,
so am I. Keep in mind, I'm offering that huge chunk of that time you said
was required in exchange for only a little time from an experienced member
of the community. I don't understand why you wouldn't encourage such a
"trade."  However, I'm experienced enough to know that you're right when
you say solving the SUID problem will take "a lot of time." Without
someone to draw upon for guidance, I'm not sure I'm ready for the risk of
this tar-baby (time sink). Yes, it's possible to use this e-list for that
purpose, but experience says that's not nearly as effective as someone
making the decision, "OK, I'll point. Here's where you need to go..."

Respectfully yours,
Richard

-- 
Richard Troy, Chief Scientist
Science Tools Corporation
rtroy@ScienceTools.com, 510-567-9957, http://ScienceTools.com/



--
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/

Re: cygwin mentors? Was: bash and the suid bit

[Corinna Vinschen]

On Thu, Apr 18, 2002 at 08:45:24AM -0700, Richard Troy wrote:
> Not this time, Corinna. A Contribution is a contribution, regardless of
> [...]
> making the decision, "OK, I'll point. Here's where you need to go..."

Sorry, but that's not how it works.  We *want* to discuss everything
public.  This is an OSS project.  Keep it public.  You're getting
exactly as much help as a group of volunteers is willing to give.

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/