Return to PORTING CVS log

Up to [local] / src / usr.bin / sudo

Annotation of src/usr.bin/sudo/PORTING, Revision 1.3

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.2       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.3     ! 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:
1.2       millert    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.2       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.2       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.2       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.