Annotation of src/usr.bin/sudo/PORTING, Revision 1.1.1.1.6.1
1.1 millert 1: Sudo porting hints
2: ==================
3:
4: Before trying to port sudo to a new architecture, please join the
5: sudo-workers mailing list (see the README file) and ask if anyone
6: has a port working or in-progress. Sudo should be fairly easy to
1.1.1.1.6.1! millert 7: port. Since it uses a configure script, most of the work is often
! 8: done for you. As long as your operating system is reasonably POSIX
! 9: compliant porting should be easy. If your operating system has a
! 10: separate library for POSIX compatibility you may need to add it by
! 11: using configure's --with-libraries option.
1.1 millert 12:
13: If your OS is an SVR4 derivative (or some approximation thereof), it may
14: be sufficient to tell configure you are runnng SVR4, something like:
15: configure foo-bar-sysv4
16: where foo is the hardware architecture and bar is the vendor.
17:
18: A possible pitfall is getdtablesize(2) which is used to get the
19: maximum number of open files the process can have. If an OS has
20: the POSIX sysconf(2) it will be used instead of getdtablesize(2).
21: ulimit(2) or getrlimit(2) can also be used on some OS's. If all
22: else fails you can use the value of NOFILE in <sys/param.h>.
23:
1.1.1.1.6.1! millert 24: Also, some operating systems have a broken implementation of POSIX
! 25: saved IDs. If sudo prints the error message "seteuid(0): Operation
! 26: not permitted" this means saved IDs are not implemented properly.
! 27: You should run configure with the "--disable-saved-ids" option and
! 28: rebuild sudo.
! 29:
! 30: Sudo tries to clear the environment of dangerous environment variables
! 31: such as LD_* to prevent shared library spoofing. If you are porting
! 32: sudo to a new OS that has shared libraries you'll want to mask out
! 33: the variables that allow one to change the shared library path.
! 34: See initial_badenv_table() in env.c to see how this is done for
! 35: various operating systems.
1.1 millert 36:
37: It is possible that on a really weird system, tgetpass() may not
38: compile. (The most common cause for this is that the "fd_set" type
39: is not defined in a place that sudo expects it to be. If you can
40: find the header file where "fd_set" is typedef'd, have tgetpass.c
41: include it and send in a bug report.)
42: Alternately, tgetpass.c may compile but not work (nothing happens
43: at the Password: prompt). It is possible that your C library
44: contains a broken or unusable crypt() function--try linking with
45: -lcrypt if that exists. Another possibility is that select() is
46: not fully functional; running configure with --with-password-timeout=0
1.1.1.1.6.1! millert 47: will disable the use of select(). If sudo prompts you for a
! 48: password but never accepts it, see below.
! 49:
! 50: Sudo detects and recognizes most common shadow password schemes
! 51: automatically. If you find that sudo is not accepting your password
! 52: and you are sure that it has been typed in correctly there are two
! 53: likely problems. One possibility is that your C library has a
! 54: broken crypt() function (see above). The other is that your operating
! 55: system is using shadow passwords and sudo has not detected that
! 56: fact. Look in config.h to see what, if any, shadow password scheme
! 57: was detected. The most common are SVR4 (HAVE_GETSPNAM will be
! 58: defined) and SecureWare (HAVE_GETPRPWNAM will be defined). Check
! 59: the manual pages on your system for "getspnam" and "getprpwnam".
! 60: If one of those exist but the appropriate define does not exist in
! 61: config.h then the problem is most likely that those routines live
! 62: in a library that sudo does not know to link against. The manual
! 63: page should tell you what library this is. You can then use the
! 64: --with-libraries option to configure to tell sudo to link with the
! 65: library in question. For example:
! 66: --with-libraries='-lgen'
! 67: would cause sudo to link in libgen which contains "getspnam" on SCO
! 68: systems.
1.1 millert 69:
70: If you are trying to port to a system without standard Berkeley
71: networking you may find that interfaces.c will not compile. This
1.1.1.1.6.1! millert 72: is most likely on OS's with STREAMS-based networking. It should
! 73: be possible to make it work by modifying the ISC streams support
1.1 millert 74: (see the _ISC #ifdef's). However, if you don't care about ip address
75: and network address support, you can just run configure with the
1.1.1.1.6.1! millert 76: --without-interfaces flag to get a do-nothing load_interfaces()
! 77: stub function.
! 78:
! 79: Sudo wants POSIX signals (sigaction and friends). If your system
! 80: lacks sigaction but has the 4.3BSD sigvec() function, sigvec() will
! 81: be used instead via the wrapper functions in sigaction.c. It is
! 82: not currently possible to use the old SVR3 and 4.2BSD signals, but
! 83: this is due more to my lack of a test machine than anything else.
1.1 millert 84:
85: If you port sudo to a new architecture, please send the output of
86: "configure", the config.log file and your changes to:
87: sudo@courtesan.com
88:
89: If you are unable to get sudo working, and you are willing to
90: give me an account on a machine, send mail to sudo@courtesan.com.
91: Note, however, that I can't make any promises.