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 for the moment I > think you'd better patch that into sendmail and procmail gnulib-style. Proper license? Please explain. Sincerely, Daniel