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