Re: [ITP] libsuexec 1.0
On 2014-08-22 00:39, D. Boland wrote: So it's settled. I will roll with fakesu. I'll re-post. Anyone know why my upload-key activation is taking so long? Or were y'all waiting for me to change my mind... Sorry, issue on our end. Your key has been activated. Yaakov
Re: [ITP] libsuexec 1.0
Hi Achim, Achim Gratz wrote: D. Boland writes: I still think you should name it differently. Marco has already mixed it up with Apache suexec⦠The idea kind of was to mix it up, so people will know what it does. Apache suexec is concerned with running new processes as a different user, so both the su and the exec part of the name make sense. Your library is concerned with inserting itself into certain calls to swap uid/gid so programs expecting a fixed mapping of some uid/gid to certain capabilities (roughly associated with the concept of a root user) work without the actual source getting patched on a system where those assumptions aren't true. Looks like different thing to me and giving it a different name surely wouldn't hurt. Ok, got the point. But the su part must stay. Because it's the super-user who needs to be simulated. Soo: susim? simsu? fakesu? Suggestions are welcome... D.
Re: [ITP] libsuexec 1.0
On 08/21/2014 06:19 AM, D. Boland wrote: Your library is concerned with inserting itself into certain calls to swap uid/gid so programs expecting a fixed mapping of some uid/gid to certain capabilities (roughly associated with the concept of a root user) work without the actual source getting patched on a system where those assumptions aren't true. Looks like different thing to me and giving it a different name surely wouldn't hurt. fakesu? I like this one. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [ITP] libsuexec 1.0
On Aug 21 06:20, Eric Blake wrote: On 08/21/2014 06:19 AM, D. Boland wrote: Your library is concerned with inserting itself into certain calls to swap uid/gid so programs expecting a fixed mapping of some uid/gid to certain capabilities (roughly associated with the concept of a root user) work without the actual source getting patched on a system where those assumptions aren't true. Looks like different thing to me and giving it a different name surely wouldn't hurt. fakesu? I like this one. Ditto. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpbfBIQqCOu7.pgp Description: PGP signature
Re: [ITP] libsuexec 1.0
Hello, D.. Thursday, August 21, 2014, 16:19:00 you wrote: susim? simsu? fakesu? Suggestions are welcome... cygsu cygroot Just 'cyg' somehow sounds better IMHO. But it's really just MHO. -- Kind regards, Pavel
Re: [ITP] libsuexec 1.0
D. Boland writes: fakesu? I'd go with fakeid personally. But that's a joke that's probably too hard to get… so fakesu is also good. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra
Re: [ITP] libsuexec 1.0
Achim Gratz wrote: D. Boland writes: fakesu? I'd go with fakeid personally. But that's a joke that's probably too hard to get⦠so fakesu is also good. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra So it's settled. I will roll with fakesu. I'll re-post. Anyone know why my upload-key activation is taking so long? Or were y'all waiting for me to change my mind... Daniel
Re: [ITP] libsuexec 1.0
On 2014-08-18 13:20, D. Boland wrote: Achim Gratz wrote: I still think you should name it differently. Marco has already mixed it up with Apache suexec The idea kind of was to mix it up, so people will know what it does. Deliberately inciting confusion isn't a good thing. If this was Apache suexec turned into a library this might make sense, but this clearly isn't. Let's find another name for it, please. Yaakov
Re: [ITP] libsuexec 1.0
D. Boland writes: I still think you should name it differently. Marco has already mixed it up with Apache suexec… The idea kind of was to mix it up, so people will know what it does. Apache suexec is concerned with running new processes as a different user, so both the su and the exec part of the name make sense. Your library is concerned with inserting itself into certain calls to swap uid/gid so programs expecting a fixed mapping of some uid/gid to certain capabilities (roughly associated with the concept of a root user) work without the actual source getting patched on a system where those assumptions aren't true. Looks like different thing to me and giving it a different name surely wouldn't hurt. I noticed that you and other people already declare the user switching technique half dead. It's a brilliant idea, you know. Because of its simplicity. I did nothing of that sort. I said that the assumptions some of those programs make aren't true on many systems and have not been for a long time. It's even patented. By referring to the Apache executable I give the technique the glory and attention it deserves. Attaching to unrelated projects' names for glory is a surefire way to rile those projects up and sow confusion among users on both sides. So most people are thinking 'Capabilities' nowadays... Sigh. This will only steer admins away from finding out how user switching works and applying it. Instead they will just run entire server processes as admin-users. Again, running applications with the least privileges needed for a given task is a tried and valid concept. SWitching uid/gid to achieve that is an implementation detail that is not relevant to all systems. Give SELinux a spin and then come back to me. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ DIY Stuff: http://Synth.Stromeko.net/DIY.html
Re: [ITP] libsuexec 1.0
Hi Daniel, On Aug 17 21:22, D. Boland wrote: Hi group, Thanks for all the critiques and suggestions regarding this new library. I have made changes accordingly. * The term 'capabilities' has been removed from the hints file, since that is not what the library is about or for. * Also the term 'multi-root' has been removed from the hints file. I think the new description in the hints file now accurately covers what the library does. * Not all functions in the library were declared. They are now. * I added a readme file. * I removed the dynamic library. This library will be static only. * I put the license under the 'Open Source Definition' license and added a reference to the complete license text. Uh, that's a bit of a problem. The text under http://opensource.org/docs/osd/ does *not* constitute a license by itself. It just describes what a license has to define to become an OSS license. For blessed OSS licenses, see http://opensource.org/licenses/. For a simple lib like this I'd suggest http://opensource.org/licenses/BSD-2-Clause or http://opensource.org/licenses/LGPL-3.0 http://cygwin.boland.nl/x86/release/libsuexec/ A LICENSE file parallel to usr/share/doc/README containing the license text would be nice. Other than that licensing issue, the package is GTG. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp7mHTQaZvPn.pgp Description: PGP signature
Re: [ITP] libsuexec 1.0
Hi Corinna, Corinna Vinschen wrote: * I put the license under the 'Open Source Definition' license and added a reference to the complete license text. Uh, that's a bit of a problem. The text under http://opensource.org/docs/osd/ does *not* constitute a license by itself. It just describes what a license has to define to become an OSS license. For blessed OSS licenses, see http://opensource.org/licenses/. For a simple lib like this I'd suggest http://opensource.org/licenses/BSD-2-Clause or http://opensource.org/licenses/LGPL-3.0 http://cygwin.boland.nl/x86/release/libsuexec/ A LICENSE file parallel to usr/share/doc/README containing the license text would be nice. I changed the license to LGPL 2.1. It has the nice short text to paste in my sources :-). I also updated the procmail package. It has Cygwin version 14 now. Finally, I sent my public key, so now I will wait for activation. Thanks, Daniel
Re: [ITP] libsuexec 1.0
D. Boland writes: Thanks for all the critiques and suggestions regarding this new library. I have made changes accordingly. I still think you should name it differently. Marco has already mixed it up with Apache suexec… Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: [ITP] libsuexec 1.0
Hi Achim, Achim Gratz wrote: D. Boland writes: Thanks for all the critiques and suggestions regarding this new library. I have made changes accordingly. I still think you should name it differently. Marco has already mixed it up with Apache suexec⦠The idea kind of was to mix it up, so people will know what it does. I noticed that you and other people already declare the user switching technique half dead. It's a brilliant idea, you know. Because of its simplicity. It's even patented. By referring to the Apache executable I give the technique the glory and attention it deserves. So most people are thinking 'Capabilities' nowadays... Sigh. This will only steer admins away from finding out how user switching works and applying it. Instead they will just run entire server processes as admin-users. Sincerely, Daniel
Re: [ITP] libsuexec 1.0
Hi group, Thanks for all the critiques and suggestions regarding this new library. I have made changes accordingly. * The term 'capabilities' has been removed from the hints file, since that is not what the library is about or for. * Also the term 'multi-root' has been removed from the hints file. I think the new description in the hints file now accurately covers what the library does. * Not all functions in the library were declared. They are now. * I added a readme file. * I removed the dynamic library. This library will be static only. * I put the license under the 'Open Source Definition' license and added a reference to the complete license text. http://cygwin.boland.nl/x86/release/libsuexec/ GTS's are welcome. Daniel
Re: [ITP] libsuexec 1.0
On Aug 16 10:05, D. Boland wrote: Hi group, This is not an existing package, but a spin-off project from porting Sendmail and Procmail to Cygwin. These programs, as you may or may not know, rely heavily on the setuid mechanism (impersonating as another user). More formally, this is called 'running as an unprivileged user' in Linux and 'privilege separation' in OpenBSD. In Cygwin, this mechanism is already implemented in the ssh daemon. Sendmail takes this idea to the extreme. It starts up as the root user and waits for connections. On connection, it starts the 'queue runner' program as an unprivileged user called 'smmsp', which handles the conversation with the remote e-mail client. If the incoming e-mail has to be delivered locally (stored on disk), the queue runner starts the procmail program, which in turn switches to the actual user the e-mail is meant for and stores it in the user's inbox. So, for instance sending an e-mail to myself involves switching through three users: root - smmsp - daniel The problem --- Up to WinXP and Win2002, porting source code for Cygwin which performed this switching of users, wasn't a big problem. In Windows, it is the 'SYSTEM' user which starts up most services, thus in effect acting as the Unix 'root' user. The difference is that SYSTEM has uid '18', while root has uid '0' in Unix. So, if porting from Unix to Cygwin one could just look for all occurances of uid '0' and replace them with '18'. Actually, this technique has been used to create the current Cygwin port of the Procmail program. As of Win7 and Win2003 this will no longer work. For security reasons, the privilege needed to impersonate another user (called 'SeCreateTokenPrivilege') has been removed from the SYSTEM user. Services (daemons) who need impersonation now have to be started by non-SYSTEM users, which have been put in the 'Administrators' group and granted the SeCreateTokenPrivilege. This works for most suid software, like the Apache webserver, but not for Sendmail and Procmail. Both programs *enforce* what is called the Capabilities model. This means that both programs actually check if they are ran by root and if not, refuse to deliver e-mail. So, simply replacing '0' with '18' in the source code has no effect. The solution The solution to this problem turns out to be very simple and elegant: *tell* Sendmail and Procmail who is the root user by overriding functions which involve getting or setting user id's. For instance: make the getuid() function return '0' when the actual user id is '18' and make the setuid() function change to uid '18' if the requested uid is '0'. Take this idea one step further and Sendmail and Procmail become 'multi-root aware'. Now I *finally* understand what you mean with multi-root. Duh. I created this library to do exacly that. On startup it assumes the root user id is '18' (SYSTEM) and the root group id is '544' (Administrators). It overrides the original getuid(), getgid(), etc. functions to return '0' if the actual uid/gid are '18' or '544'. The library makes its program 'multi-root aware' by checking if the non-SYSTEM user is a member of the 'Administrators' group and if so, simply replacing *its* uid and gid to be '0'. This totally satisfies Sendmail and Procmail. More importantly: I didn't have to change a single line in their source code (which would have been an awful lot), because the library is doing the swapping of uids/gids in the background. To use this library, put '#include suexec.h' and '-lsuexec' at a strategic location in your source code and Makefile. To make your program 'multi-root' aware and even do suid and/or sugid, place a call to 'suexec(argv[0])' in your 'main' function and set the suid and/or sgid bits on the resulting binary. http://cygwin.boland.nl/x86/release/libsuexec/ All GTG's are welcome... This looks neat. It doesn't cover the acl(2) family of functions, but these are seldom used anyway. I have just a few small nits. - suexec.h neglects to declare most of the su_* functions. This doesn't seem much of a problem at first, but it is when using this from C++, or when running a build with -Werror. May I suggest to declare all su_* functions in suexec.h? - The expression multi-root doesn't have a known meaning. The description text in setup.hint doesn't help a lot either. In a way it claims that setuid/setgid isn't available without this package, which is wrong, and it uses the expression multi-root by way of explaining it. Along these lines... - ... it would be much more helpful if you could explain what the package is doing, basically the full content of this mail of yours I'm just replying to, in a README file under /usr/share/doc/suexec/. Keep in mind that the description text in setup.hint is (still) not visible from setup-arch.exe, thus almost nobody will read it. Also, to
Re: [ITP] libsuexec 1.0
In Windows, it is the 'SYSTEM' user which starts up most services, thus in effect acting as the Unix 'root' user. The difference is that SYSTEM has uid '18', while root has uid '0' in Unix. No, there are much larger differences between a capability based system and this. With capabilities, whatever you call a root user might not even exist and if it does, it might not have the capabilities you're associating with root on a classical UNIX system. So, if porting from Unix to Cygwin one could just look for all occurances of uid '0' and replace them with '18'. Actually, this technique has been used to create the current Cygwin port of the Procmail program. That's a long winded way of saying that these programs are not capability-aware. As of Win7 and Win2003 this will no longer work. For security reasons, the privilege needed to impersonate another user (called 'SeCreateTokenPrivilege') has been removed from the SYSTEM user. Services (daemons) who need impersonation now have to be started by non-SYSTEM users, which have been put in the 'Administrators' group and granted the SeCreateTokenPrivilege. This works for most suid software, like the Apache webserver, but not for Sendmail and Procmail. Both programs *enforce* what is called the Capabilities model. This means that both programs actually check if they are ran by root and if not, refuse to deliver e-mail. So, simply replacing '0' with '18' in the source code has no effect. No, actually they have no idea what a capability is and use the UID as a proxy for certain capabilities. Which is wrong when actual capabilities come into play. The solution The solution to this problem turns out to be very simple and elegant: *tell* Sendmail and Procmail who is the root user by overriding functions which involve getting or setting user id's. For instance: make the getuid() function return '0' when the actual user id is '18' and make the setuid() function change to uid '18' if the requested uid is '0'. Take this idea one step further and Sendmail and Procmail become 'multi-root aware'. Except that SYSTEM is not root. Depending on what capabilities those programs actually expect from root it may or may not have them. And I wish you'd stop talking about multi-root, there is no such thing and never will be, since there is no root at all. I created this library to do exacly that. On startup it assumes the root user id is '18' (SYSTEM) and the root group id is '544' (Administrators). It overrides the original getuid(), getgid(), etc. functions to return '0' if the actual uid/gid are '18' or '544'. The library makes its program 'multi-root aware' by checking if the non-SYSTEM user is a member of the 'Administrators' group and if so, simply replacing *its* uid and gid to be '0'. This totally satisfies Sendmail and Procmail. So if I'm a member of the administrators group those programs will use administrative rights while delivering mail to my inbox even though they don't need to? That doesn't sound desirable to me in any way. More importantly: I didn't have to change a single line in their source code (which would have been an awful lot), because the library is doing the swapping of uids/gids in the background. As much as I had to patch it up in a time long ago I'd rather have sendmail die as it's way past its best-before-use date, but then I wasn't planning on using it anyway. To use this library, put '#include suexec.h' and '-lsuexec' at a strategic location in your source code and Makefile. To make your program 'multi-root' aware and even do suid and/or sugid, place a call to 'suexec(argv[0])' in your 'main' function and set the suid and/or sgid bits on the resulting binary. http://cygwin.boland.nl/x86/release/libsuexec/ This library doesn't do anything su-like or exec, so I think it is misnamed. All GTG's are welcome... At the very least you're missing a proper license. But for the moment I think you'd better patch that into sendmail and procmail gnulib-style. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada
Re: [ITP] libsuexec 1.0
On 16/08/2014 11:28, Achim Gratz wrote: http://cygwin.boland.nl/x86/release/libsuexec/ This library doesn't do anything su-like or exec, so I think it is misnamed. All GTG's are welcome... suexec is the upstream name. http://httpd.apache.org/docs/2.2/suexec.html Marco
Re: [ITP] libsuexec 1.0
Hi Achim, Achim Gratz wrote: In Windows, it is the 'SYSTEM' user which starts up most services, thus in effect acting as the Unix 'root' user. The difference is that SYSTEM has uid '18', while root has uid '0' in Unix. No, there are much larger differences between a capability based system and this. With capabilities, whatever you call a root user might not even exist and if it does, it might not have the capabilities you're associating with root on a classical UNIX system. I am fully aware that I am touching a very sensitive subject here. I shouldn't have mentioned the word 'Capabilities'. But I sense something deeper here. Correct me if I'm wrong, but do you really love Unix? I think not. There is no such thing as a classical Unix system. There is only Unix. Prove to me that you really love Unix. So, if porting from Unix to Cygwin one could just look for all occurances of uid '0' and replace them with '18'. Actually, this technique has been used to create the current Cygwin port of the Procmail program. That's a long winded way of saying that these programs are not capability-aware. I will remove the term from my hints file. As of Win7 and Win2003 this will no longer work. For security reasons, the privilege needed to impersonate another user (called 'SeCreateTokenPrivilege') has been removed from the SYSTEM user. Services (daemons) who need impersonation now have to be started by non-SYSTEM users, which have been put in the 'Administrators' group and granted the SeCreateTokenPrivilege. This works for most suid software, like the Apache webserver, but not for Sendmail and Procmail. Both programs *enforce* what is called the Capabilities model. This means that both programs actually check if they are ran by root and if not, refuse to deliver e-mail. So, simply replacing '0' with '18' in the source code has no effect. No, actually they have no idea what a capability is and use the UID as a proxy for certain capabilities. Which is wrong when actual capabilities come into play. The solution The solution to this problem turns out to be very simple and elegant: *tell* Sendmail and Procmail who is the root user by overriding functions which involve getting or setting user id's. For instance: make the getuid() function return '0' when the actual user id is '18' and make the setuid() function change to uid '18' if the requested uid is '0'. Take this idea one step further and Sendmail and Procmail become 'multi-root aware'. Except that SYSTEM is not root. Depending on what capabilities those programs actually expect from root it may or may not have them. And I wish you'd stop talking about multi-root, there is no such thing and never will be, since there is no root at all. No root at all?? You're stuck on words. Root is a type of super-user and SYSTEM is also. Don't be tight. Prove to me that you really love Unix. I created this library to do exacly that. On startup it assumes the root user id is '18' (SYSTEM) and the root group id is '544' (Administrators). It overrides the original getuid(), getgid(), etc. functions to return '0' if the actual uid/gid are '18' or '544'. The library makes its program 'multi-root aware' by checking if the non-SYSTEM user is a member of the 'Administrators' group and if so, simply replacing *its* uid and gid to be '0'. This totally satisfies Sendmail and Procmail. So if I'm a member of the administrators group those programs will use administrative rights while delivering mail to my inbox even though they don't need to? That doesn't sound desirable to me in any way. Nope. They will not use administrative rights. The opposite is true. You, as a member of the Admin group, need those extra rights so procmail can deliver as an *unprivileged* user. If procmail or sendmail 'see' that they have been started by a non-super-user, they will refuse to switch to the unprivileged user and deliver e-mail. More importantly: I didn't have to change a single line in their source code (which would have been an awful lot), because the library is doing the swapping of uids/gids in the background. As much as I had to patch it up in a time long ago I'd rather have sendmail die as it's way past its best-before-use date, but then I wasn't planning on using it anyway. To use this library, put '#include suexec.h' and '-lsuexec' at a strategic location in your source code and Makefile. To make your program 'multi-root' aware and even do suid and/or sugid, place a call to 'suexec(argv[0])' in your 'main' function and set the suid and/or sgid bits on the resulting binary. http://cygwin.boland.nl/x86/release/libsuexec/ This library doesn't do anything su-like or exec, so I think it is misnamed. All GTG's are welcome... At the very least you're missing a proper license. But
Re: [ITP] libsuexec 1.0
D. Boland writes: At the very least you're missing a proper license. But for the moment I think you'd better patch that into sendmail and procmail gnulib-style. Proper license? Please explain. It appears you want to license under some version of the GPL. No license document is actually included that spells out what that means. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: [ITP] libsuexec 1.0
Marco Atzeri writes: suexec is the upstream name. http://httpd.apache.org/docs/2.2/suexec.html I fail to see the relation, APache suexec seems to do quite different things. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Waldorf MIDI Implementation additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs
Re: [ITP] libsuexec 1.0
On Aug 16 11:28, Achim Gratz wrote: In Windows, it is the 'SYSTEM' user which starts up most services, thus in effect acting as the Unix 'root' user. The difference is that SYSTEM has uid '18', while root has uid '0' in Unix. No, there are much larger differences between a capability based system and this. With capabilities, whatever you call a root user might not even exist and if it does, it might not have the capabilities you're associating with root on a classical UNIX system. Good point. A README file should perhaps refrain from calling what sendmail does a capability model. It's just a typical old-style Unix service expecting uid 0 is something special. This isn't simply a Cygwin problem. So, if porting from Unix to Cygwin one could just look for all occurances of uid '0' and replace them with '18'. Actually, this technique has been used to create the current Cygwin port of the Procmail program. That's a long winded way of saying that these programs are not capability-aware. As of Win7 and Win2003 this will no longer work. For security reasons, the privilege needed to impersonate another user (called 'SeCreateTokenPrivilege') has been removed from the SYSTEM user. Services (daemons) who need impersonation now have to be started by non-SYSTEM users, which have been put in the 'Administrators' group and granted the SeCreateTokenPrivilege. This works for most suid software, like the Apache webserver, but not for Sendmail and Procmail. Both programs *enforce* what is called the Capabilities model. This means that both programs actually check if they are ran by root and if not, refuse to deliver e-mail. So, simply replacing '0' with '18' in the source code has no effect. No, actually they have no idea what a capability is and use the UID as a proxy for certain capabilities. Which is wrong when actual capabilities come into play. The solution The solution to this problem turns out to be very simple and elegant: *tell* Sendmail and Procmail who is the root user by overriding functions which involve getting or setting user id's. For instance: make the getuid() function return '0' when the actual user id is '18' and make the setuid() function change to uid '18' if the requested uid is '0'. Take this idea one step further and Sendmail and Procmail become 'multi-root aware'. Except that SYSTEM is not root. Depending on what capabilities those programs actually expect from root it may or may not have them. And I wish you'd stop talking about multi-root, there is no such thing and never will be, since there is no root at all. Good point. The multi-root expression puzzles me, too. Before this mail I vaguely thought about some multi-user ability. I'm not claiming that my misunderstanding is a role model, but the expression certainly *is* misleading. I created this library to do exacly that. On startup it assumes the root user id is '18' (SYSTEM) and the root group id is '544' (Administrators). It overrides the original getuid(), getgid(), etc. functions to return '0' if the actual uid/gid are '18' or '544'. The library makes its program 'multi-root aware' by checking if the non-SYSTEM user is a member of the 'Administrators' group and if so, simply replacing *its* uid and gid to be '0'. This totally satisfies Sendmail and Procmail. So if I'm a member of the administrators group those programs will use administrative rights while delivering mail to my inbox even though they don't need to? That doesn't sound desirable to me in any way. No, they won't. The lib just converts the uid of the current user to 0 within the application to keep it blissfully ignorant. This allows to run applications claiming uid 0 is something special from SYSTEM or cyg_server as service, without the need to patch the sources. It's not exactly a bad idea for such services if it makes them work, I think. More importantly: I didn't have to change a single line in their source code (which would have been an awful lot), because the library is doing the swapping of uids/gids in the background. As much as I had to patch it up in a time long ago I'd rather have sendmail die as it's way past its best-before-use date, but then I wasn't planning on using it anyway. Postfix for Cygwin would be *so* nice. Sigh. It would also be nice to get Exim running on 64 bit. But either way, sendmail is still kind of a de-facto standard, so it's not bad to get it into the distro, just as Fedora comes with sendmail, postfix, exim, etc. Choice is good. To use this library, put '#include suexec.h' and '-lsuexec' at a strategic location in your source code and Makefile. To make your program 'multi-root' aware and even do suid and/or sugid, place a call to 'suexec(argv[0])' in your 'main' function and set the suid and/or sgid bits on the resulting
Re: [ITP] libsuexec 1.0
Corinna Vinschen writes: So if I'm a member of the administrators group those programs will use administrative rights while delivering mail to my inbox even though they don't need to? That doesn't sound desirable to me in any way. No, they won't. The lib just converts the uid of the current user to 0 within the application to keep it blissfully ignorant. This allows to run applications claiming uid 0 is something special from SYSTEM or cyg_server as service, without the need to patch the sources. It's not exactly a bad idea for such services if it makes them work, I think. Good, I haven't checked the sources so I'll believe it. Actually I've been thinking before that maybe it was a good idea to map group 544 to euid 0 (so that shells would be showing # as prompt without extra nudging), but I came to the conclusion that it probably makes more trouble than it's worth. Maybe I revisit that question some time… But anyway, I stick to my earlier assessment that this functionality should be incorporated into applications that need it on the source level, gnulib-style. That shim is small emough so that the resulting duplication doesn't matter. I can't think of a good reason to have that as a DLL on the other hand (other than if you'd wanted to shim at runtime, which is IMHO a bad idea). Postfix for Cygwin would be *so* nice. Sigh. It would also be nice to get Exim running on 64 bit. But either way, sendmail is still kind of a de-facto standard, so it's not bad to get it into the distro, just as Fedora comes with sendmail, postfix, exim, etc. Choice is good. The idea of exposing that server to the world doesn't sound exactly appealing to me. But yes, choice is good. :-) Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: [ITP] libsuexec 1.0
On Aug 16 12:50, Achim Gratz wrote: Corinna Vinschen writes: So if I'm a member of the administrators group those programs will use administrative rights while delivering mail to my inbox even though they don't need to? That doesn't sound desirable to me in any way. No, they won't. The lib just converts the uid of the current user to 0 within the application to keep it blissfully ignorant. This allows to run applications claiming uid 0 is something special from SYSTEM or cyg_server as service, without the need to patch the sources. It's not exactly a bad idea for such services if it makes them work, I think. Good, I haven't checked the sources so I'll believe it. Actually I've been thinking before that maybe it was a good idea to map group 544 to euid 0 (so that shells would be showing # as prompt without extra nudging), but I came to the conclusion that it probably makes more trouble than it's worth. Maybe I revisit that question some time… uid/gid == 0 is *only* used by applications which are in the server and switch-user-context business. It's kind of a bad idea anyway, and I'm constantly puzzled why there are so many applications out there using this test. Applications *not* running with certain privileges will not be able to use certain functions anyway. The inability to use certain function is in 99% of the cases indication enough that the application is running in a low-privilege context and not running as a system-wide service. So, while it's kind of nice from a compatibility POV to use uid/gid 0 in certain scenarios, it doesn't make much sense most of the time. Especially not on a system which *is* capabiliy based rather than uid/gid==0 based. This is a problem on other sytems as well. Even on Linux capabilities are getting more and more important and the uid/gid loses its meaning. But anyway, I stick to my earlier assessment that this functionality should be incorporated into applications that need it on the source level, gnulib-style. That shim is small emough so that the resulting duplication doesn't matter. I can't think of a good reason to have that as a DLL on the other hand (other than if you'd wanted to shim at runtime, which is IMHO a bad idea). Point taken. Maybe it should be provided as a static lib only. The size added to the executable is, in fact, negligible. Postfix for Cygwin would be *so* nice. Sigh. It would also be nice to get Exim running on 64 bit. But either way, sendmail is still kind of a de-facto standard, so it's not bad to get it into the distro, just as Fedora comes with sendmail, postfix, exim, etc. Choice is good. The idea of exposing that server to the world doesn't sound exactly appealing to me. Heh :) So you're going to provide a postfix port really soon now? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpBCsVm3XvWf.pgp Description: PGP signature
