=================================================================== RCS file: /cvsrepo/anoncvs/cvs/src/usr.bin/sudo/Attic/PORTING,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.1.8.1 diff -c -r1.1.1.1 -r1.1.1.1.8.1 *** src/usr.bin/sudo/Attic/PORTING 1999/11/18 16:29:01 1.1.1.1 --- src/usr.bin/sudo/Attic/PORTING 2002/01/18 16:14:44 1.1.1.1.8.1 *************** *** 4,11 **** Before trying to port sudo to a new architecture, please join the sudo-workers mailing list (see the README file) and ask if anyone has a port working or in-progress. Sudo should be fairly easy to ! port. Since it uses a configure script, most of the work should ! be done for you. If your OS is an SVR4 derivative (or some approximation thereof), it may be sufficient to tell configure you are runnng SVR4, something like: --- 4,14 ---- Before trying to port sudo to a new architecture, please join the sudo-workers mailing list (see the README file) and ask if anyone has a port working or in-progress. Sudo should be fairly easy to ! port. Since it uses a configure script, most of the work is often ! done for you. As long as your operating system is reasonably POSIX ! compliant porting should be easy. If your operating system has a ! separate library for POSIX compatibility you may need to add it by ! using configure's --with-libraries option. If your OS is an SVR4 derivative (or some approximation thereof), it may be sufficient to tell configure you are runnng SVR4, something like: *************** *** 18,29 **** ulimit(2) or getrlimit(2) can also be used on some OS's. If all else fails you can use the value of NOFILE in . ! Sudo tries to clear the environment of dangerous envariables like ! LD_* to prevent shared library spoofing. If you are porting sudo ! to a new OS that has shared libraries you'll want to mask out the ! variables that allow one to change the shared library path. See ! badenv_table() in sudo.c to see how this is done for various OS's. It is possible that on a really weird system, tgetpass() may not compile. (The most common cause for this is that the "fd_set" type is not defined in a place that sudo expects it to be. If you can --- 21,39 ---- ulimit(2) or getrlimit(2) can also be used on some OS's. If all else fails you can use the value of NOFILE in . ! Also, some operating systems have a broken implementation of POSIX ! saved IDs. If sudo prints the error message "seteuid(0): Operation ! not permitted" this means saved IDs are not implemented properly. ! You should run configure with the "--disable-saved-ids" option and ! rebuild sudo. + Sudo tries to clear the environment of dangerous environment variables + such as LD_* to prevent shared library spoofing. If you are porting + sudo to a new OS that has shared libraries you'll want to mask out + the variables that allow one to change the shared library path. + See initial_badenv_table() in env.c to see how this is done for + various operating systems. + It is possible that on a really weird system, tgetpass() may not compile. (The most common cause for this is that the "fd_set" type is not defined in a place that sudo expects it to be. If you can *************** *** 34,48 **** contains a broken or unusable crypt() function--try linking with -lcrypt if that exists. Another possibility is that select() is not fully functional; running configure with --with-password-timeout=0 ! will disable the use of select(). If you are trying to port to a system without standard Berkeley networking you may find that interfaces.c will not compile. This ! is most likely on OS's with STREAMS-based networking. It should be ! possible to make it work by modifying the ISC streams support (see the _ISC #ifdef's). However, if you don't care about ip address and network address support, you can just run configure with the ! --without-interfaces flag to get a do-nothing load_interfaces() stub function. If you port sudo to a new architecture, please send the output of "configure", the config.log file and your changes to: --- 44,86 ---- contains a broken or unusable crypt() function--try linking with -lcrypt if that exists. Another possibility is that select() is not fully functional; running configure with --with-password-timeout=0 ! will disable the use of select(). If sudo prompts you for a ! password but never accepts it, see below. + Sudo detects and recognizes most common shadow password schemes + automatically. If you find that sudo is not accepting your password + and you are sure that it has been typed in correctly there are two + likely problems. One possibility is that your C library has a + broken crypt() function (see above). The other is that your operating + system is using shadow passwords and sudo has not detected that + fact. Look in config.h to see what, if any, shadow password scheme + was detected. The most common are SVR4 (HAVE_GETSPNAM will be + defined) and SecureWare (HAVE_GETPRPWNAM will be defined). Check + the manual pages on your system for "getspnam" and "getprpwnam". + If one of those exist but the appropriate define does not exist in + config.h then the problem is most likely that those routines live + in a library that sudo does not know to link against. The manual + page should tell you what library this is. You can then use the + --with-libraries option to configure to tell sudo to link with the + library in question. For example: + --with-libraries='-lgen' + would cause sudo to link in libgen which contains "getspnam" on SCO + systems. + If you are trying to port to a system without standard Berkeley networking you may find that interfaces.c will not compile. This ! is most likely on OS's with STREAMS-based networking. It should ! be possible to make it work by modifying the ISC streams support (see the _ISC #ifdef's). However, if you don't care about ip address and network address support, you can just run configure with the ! --without-interfaces flag to get a do-nothing load_interfaces() ! stub function. ! ! Sudo wants POSIX signals (sigaction and friends). If your system ! lacks sigaction but has the 4.3BSD sigvec() function, sigvec() will ! be used instead via the wrapper functions in sigaction.c. It is ! not currently possible to use the old SVR3 and 4.2BSD signals, but ! this is due more to my lack of a test machine than anything else. If you port sudo to a new architecture, please send the output of "configure", the config.log file and your changes to: