* will bash honor the suid bit or not? @ 2002-04-17 19:36 Richard Troy 2002-04-17 20:31 ` Larry Hall (RFK Partners, Inc) 2002-04-18 1:57 ` Corinna Vinschen 0 siblings, 2 replies; 12+ messages in thread From: Richard Troy @ 2002-04-17 19:36 UTC (permalink / raw) To: cygwin 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/ ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: will bash honor the suid bit or not? 2002-04-17 19:36 will bash honor the suid bit or not? Richard Troy @ 2002-04-17 20:31 ` Larry Hall (RFK Partners, Inc) 2002-04-17 21:44 ` Richard Troy 2002-04-18 1:57 ` Corinna Vinschen 1 sibling, 1 reply; 12+ messages in thread From: Larry Hall (RFK Partners, Inc) @ 2002-04-17 20:31 UTC (permalink / raw) To: Richard Troy, cygwin 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/ ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: will bash honor the suid bit or not? 2002-04-17 20:31 ` Larry Hall (RFK Partners, Inc) @ 2002-04-17 21:44 ` Richard Troy 2002-04-17 23:57 ` Sam Edge 0 siblings, 1 reply; 12+ messages in thread From: Richard Troy @ 2002-04-17 21:44 UTC (permalink / raw) To: Larry Hall (RFK Partners, Inc); +Cc: cygwin 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/ ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: will bash honor the suid bit or not? 2002-04-17 21:44 ` Richard Troy @ 2002-04-17 23:57 ` Sam Edge 0 siblings, 0 replies; 12+ messages in thread From: Sam Edge @ 2002-04-17 23:57 UTC (permalink / raw) To: cygwin > 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/ ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: will bash honor the suid bit or not? 2002-04-17 19:36 will bash honor the suid bit or not? Richard Troy 2002-04-17 20:31 ` Larry Hall (RFK Partners, Inc) @ 2002-04-18 1:57 ` Corinna Vinschen 2002-04-18 7:35 ` cygwin mentors? Was: bash and the suid bit Richard Troy 1 sibling, 1 reply; 12+ messages in thread From: Corinna Vinschen @ 2002-04-18 1:57 UTC (permalink / raw) To: cygwin 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/ ^ permalink raw reply [flat|nested] 12+ messages in thread
* cygwin mentors? Was: bash and the suid bit 2002-04-18 1:57 ` Corinna Vinschen @ 2002-04-18 7:35 ` Richard Troy 2002-04-18 7:49 ` Corinna Vinschen 0 siblings, 1 reply; 12+ messages in thread From: Richard Troy @ 2002-04-18 7:35 UTC (permalink / raw) To: Corinna Vinschen > 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/ ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: cygwin mentors? Was: bash and the suid bit 2002-04-18 7:35 ` cygwin mentors? Was: bash and the suid bit Richard Troy @ 2002-04-18 7:49 ` Corinna Vinschen 2002-04-18 8:52 ` Richard Troy 0 siblings, 1 reply; 12+ messages in thread From: Corinna Vinschen @ 2002-04-18 7:49 UTC (permalink / raw) To: cygwin 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/ ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: cygwin mentors? Was: bash and the suid bit 2002-04-18 7:49 ` Corinna Vinschen @ 2002-04-18 8:52 ` Richard Troy 2002-04-18 12:26 ` Corinna Vinschen 0 siblings, 1 reply; 12+ messages in thread From: Richard Troy @ 2002-04-18 8:52 UTC (permalink / raw) To: Corinna Vinschen > > > 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/ ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: cygwin mentors? Was: bash and the suid bit 2002-04-18 8:52 ` Richard Troy @ 2002-04-18 12:26 ` Corinna Vinschen 0 siblings, 0 replies; 12+ messages in thread From: Corinna Vinschen @ 2002-04-18 12:26 UTC (permalink / raw) To: cygwin 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/ ^ permalink raw reply [flat|nested] 12+ messages in thread
[parent not found: <Pine.LNX.4.33.0204180729480.1389-100000@denzel.in>]
* RE: cygwin mentors? Was: bash and the suid bit [not found] <Pine.LNX.4.33.0204180729480.1389-100000@denzel.in> @ 2002-04-18 8:29 ` Justin MacCarthy 0 siblings, 0 replies; 12+ messages in thread From: Justin MacCarthy @ 2002-04-18 8:29 UTC (permalink / raw) To: Richard Troy, cygwin Hi Richard, a short answer pretty busy, hopes its enough to get you started... > Tell me about it, Justin! > No, Nobody mentioned that! > How does it work? Is it part of the OS or an add-on? It's a Win2000 native service , look in services Description : "Enables starting processes under alternate credentials" Nearest thing to sudo (ala Linux) I know of > Also, can it be ported/made to work on NT? Might need to use the CreateProcessWithLogonW http://msdn.microsoft.com/library/en-us/dnwxp/html/appsec.asp http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/pro thred_2gl3.asp > If it only works on W2000, it might not be good enough for my needs... > Only works on Win2000 AFAIK , although might in XP etc. http://support.microsoft.com/directory/article.asp?ID=KB;EN-US;Q294676& http://www.microsoft.com/windows2000/en/server/help/windows_security_runas.h tm Actually one of those articles mentions XP so..... > Thanks for your reply, > Richard > > -- > Richard Troy, Chief Scientist > Science Tools Corporation > rtroy@ScienceTools.com, 510-567-9957, http://ScienceTools.com/ > > On Thu, 18 Apr 2002, Justin MacCarthy wrote: > > > Date: Thu, 18 Apr 2002 15:28:25 +0100 > > From: Justin MacCarthy <macarthy@iol.ie> > > To: Richard Troy <rtroy@sciencetools.com> > > Subject: RE: cygwin mentors? Was: bash and the suid bit > > > > I haven't followed this tread, but I had a quick look , did > anyone mention > > the RunAs service in WIn2000? > > > > Might solve your problem ??? > > > > Justin > > > > > -- 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/ ^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: cygwin mentors? Was: bash and the suid bit @ 2002-04-19 13:44 Heribert Dahms 2002-04-20 9:47 ` Richard Troy 0 siblings, 1 reply; 12+ messages in thread From: Heribert Dahms @ 2002-04-19 13:44 UTC (permalink / raw) To: 'Richard Troy', Corinna Vinschen Hi Richard, if it's that important for your company's project (that you work like me 50% of each 25h day 8-) why don't you pay Red Hat per hour or day, so Corinna or Chris work for you in their prime time? -----Original Message----- From: Richard Troy [mailto:rtroy@sciencetools.com] Sent: Donnerstag, 18. April 2002 17:45 To: Corinna Vinschen Subject: Re: cygwin mentors? Was: bash and the suid bit [Heribert] [snip] 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. [Heribert] [snip] -- 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/ ^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: cygwin mentors? Was: bash and the suid bit 2002-04-19 13:44 Heribert Dahms @ 2002-04-20 9:47 ` Richard Troy 0 siblings, 0 replies; 12+ messages in thread From: Richard Troy @ 2002-04-20 9:47 UTC (permalink / raw) To: Heribert Dahms; +Cc: Corinna Vinschen On Fri, 19 Apr 2002, Heribert Dahms wrote: > Hi Richard, > > if it's that important for your company's project > (that you work like me 50% of each 25h day 8-) > why don't you pay Red Hat per hour or day, > so Corinna or Chris work for you in their prime time? Hi Heribert, Yes, that's a reasonable suggestion. I haven't read much of Chris' posts, but Corinna has written a lot of posts with 'suid' in them and I've read a lot of those. Clearly, she's a sharp cookie, and it would be a privilege to have her working on code for me. However, I think she and her present management would object to the terms of the employment contract! If she got the same deal as I have, she'd have to work 16+ hour work days, every day (no weekends, holidays, vacation, sick time), barely any pay, and would be expected to write bug-free code! -smile- Another consideration is feasibility: How close is the code already? And, if it's not very close, are there good alternatives for what I want to do? Please see my next post... Thanks for your suggestion, Richard -- Richard Troy, Chief Scientist Science Tools Corporation rtroy@ScienceTools.com, 510-567-9957, http://ScienceTools.com/ On Fri, 19 Apr 2002, Heribert Dahms wrote: > -----Original Message----- > From: Richard Troy [mailto:rtroy@sciencetools.com] > Sent: Donnerstag, 18. April 2002 17:45 > To: Corinna Vinschen > Subject: Re: cygwin mentors? Was: bash and the suid bit > > > [Heribert] [snip] > 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. > [Heribert] [snip] -- 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/ ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2002-04-20 16:36 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2002-04-17 19:36 will bash honor the suid bit or not? Richard Troy 2002-04-17 20:31 ` Larry Hall (RFK Partners, Inc) 2002-04-17 21:44 ` Richard Troy 2002-04-17 23:57 ` Sam Edge 2002-04-18 1:57 ` Corinna Vinschen 2002-04-18 7:35 ` cygwin mentors? Was: bash and the suid bit Richard Troy 2002-04-18 7:49 ` Corinna Vinschen 2002-04-18 8:52 ` Richard Troy 2002-04-18 12:26 ` Corinna Vinschen [not found] <Pine.LNX.4.33.0204180729480.1389-100000@denzel.in> 2002-04-18 8:29 ` Justin MacCarthy 2002-04-19 13:44 Heribert Dahms 2002-04-20 9:47 ` Richard Troy
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).