src/usr.bin/sudo/UPGRADE - annotate

Return to UPGRADE CVS log

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

Annotation of src/usr.bin/sudo/UPGRADE, Revision 1.4

1.1 millert 1: Notes on upgrading from an older release
2: ========================================
3:
1.4 ! millert 4: o Upgrading from a version prior to 1.7.0:
! 5:
! 6: Starting with sudo 1.7.0 comments in the sudoers file must not
! 7: have a digit or minus sign immediately after the comment character
! 8: ('#'). Otherwise, the comment may be interpreted as a user or
! 9: group ID.
! 10:
! 11: When sudo is build with LDAP support the /etc/nsswitch.conf file is
! 12: now used to determine the sudoers seach order. sudo will default to
! 13: only using /etc/sudoers unless /etc/nsswitch.conf says otherwise.
! 14: This can be changed with an nsswitch.conf line, e.g.:
! 15: sudoers: ldap files
! 16: Would case LDAP to be searched first, then the sudoers file.
! 17: To restore the pre-1.7.0 behavior, run configure with the
! 18: --with-nsswitch=no flag.
! 19:
! 20: Sudo now ignores user .ldaprc files as well as system LDAP defaults.
! 21: All LDAP configuration is now in /etc/ldap.conf (or whichever file
! 22: was specified by configure's --with-ldap-conf-file option).
! 23: If you are using TLS, you may now need to specify:
! 24: tls_checkpeer no
! 25: in sudo's ldap.conf unless ldap.conf references a valid certificate
! 26: authority file(s).
! 27:
! 28: Please also see the WHATSNEW file for a list of new features in
! 29: sudo 1.7.0.
! 30:
1.3 millert 31: o Upgrading from a version prior to 1.6.9:
32:
33: Starting with sudo 1.6.9, if an OS supports a modular authentication
34: method such as PAM, it will be used by default by configure.
35:
36: Environment variable handling has changed significantly in sudo
37: 1.6.9. Prior to version 1.6.9, sudo would preserve the user's
38: environment, pruning out potentially dangerous variables.
39: Beginning with sudo 1.6.9, the envionment is reset to a default
40: set of values with only a small number of "safe" variables
41: preserved. To preserve specific environment variables, add
42: them to the "env_keep" list in sudoers. E.g.
43:
44: Defaults env_keep += "EDITOR"
45:
46: The old behavior can be restored by negating the "env_reset"
47: option in sudoers. E.g.
48:
49: Defaults !env_reset
50:
51: There have also been changes to how the "env_keep" and
52: "env_check" options behave.
53:
54: Prior to sudo 1.6.9, the TERM and PATH environment variables
55: would always be preserved even if the env_keep option was
56: redefined. That is no longer the case. Consequently, if
57: env_keep is set with "=" and not simply appended to (i.e. using
58: "+="), PATH and TERM must be explicitly included in the list
59: of environment variables to keep. The LOGNAME, SHELL, USER,
60: and USERNAME environment variables are still always set.
61:
62: Additionally, the env_check setting previously had no effect
63: when env_reset was set (which is now on by default). Starting
64: with sudo 1.6.9, environment variables listed in env_check are
65: also preserved in the env_reset case, provided that they do not
66: contain a '/' or '%' character. Note that it is not necessary
67: to also list a variable in env_keep--having it in env_check is
68: sufficent.
69:
70: The default lists of variables to be preserved and/or checked
71: are displayed when sudo is run by root with the -V flag.
72:
1.2 millert 73: o Upgrading from a version prior to 1.6.8:
74:
75: Prior to sudo 1.6.8, if /var/run did not exist, sudo would put
76: the timestamp files in /tmp/.odus. As of sudo 1.6.8, the
77: timestamp files will be placed in /var/adm/sudo or /usr/adm/sudo
78: if there is no /var/run directory. This directory will be
79: created if it does not already exist.
80:
81: Previously, a sudoers entry that explicitly prohibited running
82: a command as a certain user did not override a previous entry
83: allowing the same command. This has been fixed in sudo 1.6.8
84: such that the last match is now used (as it is documented).
85: Hopefully no one was depending on the previous (buggy) beghavior.
86:
1.1 millert 87: o Upgrading from a version prior to 1.6:
88:
89: As of sudo 1.6, parsing of runas entries and the NOPASSWD tag
90: has changed. Prior to 1.6, a runas specifier applied only to
91: a single command directly following it. Likewise, the NOPASSWD
92: tag only allowed the command directly following it to be run
93: without a password. Starting with sudo 1.6, both the runas
94: specifier and the NOPASSWD tag are "sticky" for an entire
95: command list. So, given the following line in sudo < 1.6
96:
97: millert ALL=(daemon) NOPASSWD:/usr/bin/whoami,/bin/ls
98:
99: millert would be able to run /usr/bin/whoami as user daemon
100: without a password and /bin/ls as root with a password.
101:
102: As of sudo 1.6, the same line now means that millert is able
103: to run run both /usr/bin/whoami and /bin/ls as user daemon
104: without a password. To expand on this, take the following
105: example:
106:
107: millert ALL=(daemon) NOPASSWD:/usr/bin/whoami, (root) /bin/ls, \
108: /sbin/dump
109:
110: millert can run /usr/bin/whoami as daemon and /bin/ls and
111: /sbin/dump as root. No password need be given for either
112: command. In other words, the "(root)" sets the default runas
113: user to root for the rest of the list. If we wanted to require
114: a password for /bin/ls and /sbin/dump the line could be written
115: thusly:
116:
117: millert ALL=(daemon) NOPASSWD:/usr/bin/whoami, \
118: (root) PASSWD:/bin/ls, /sbin/dump
119:
120: Additionally, sudo now uses a per-user timestamp directory
121: instead of a timestamp file. This allows tty timestamps to
122: simply be files within the user's timestamp dir. For the
123: default, non-tty case, the timestamp on the directory itself
124: is used.
125:
126: Also, the temporary file used by visudo is now /etc/sudoers.tmp
127: since some versions of vipw on systems with shadow passwords use
128: /etc/stmp for the temporary shadow file.
129:
130: o Upgrading from a version prior to 1.5:
131:
132: By default, sudo expects the sudoers file to be mode 0440 and
133: to be owned by user and group 0. This differs from version 1.4
134: and below which expected the sudoers file to be mode 0400 and
135: to be owned by root. Doing a `make install' will set the sudoers
136: file to the new mode and group. If sudo encounters a sudoers
137: file with the old permissions it will attempt to update it to
138: the new scheme. You cannot, however, use a sudoers file with
139: the new permissions with an old sudo binary. It is suggested
140: that if have a means of distributing sudo you distribute the
141: new binaries first, then the new sudoers file (or you can leave
142: sudoers as is and sudo will fix the permissions itself as long
1.2 millert 143: as sudoers is on a local file system).