Annotation of src/usr.bin/sudo/UPGRADE, Revision 1.1.1.1
1.1 millert 1: Notes on upgrading from an older release
2: ========================================
3:
4: o Upgrading from a version prior to 1.6:
5:
6: As of sudo 1.6, parsing of runas entries and the NOPASSWD tag
7: has changed. Prior to 1.6, a runas specifier applied only to
8: a single command directly following it. Likewise, the NOPASSWD
9: tag only allowed the command directly following it to be run
10: without a password. Starting with sudo 1.6, both the runas
11: specifier and the NOPASSWD tag are "sticky" for an entire
12: command list. So, given the following line in sudo < 1.6
13:
14: millert ALL=(daemon) NOPASSWD:/usr/bin/whoami,/bin/ls
15:
16: millert would be able to run /usr/bin/whoami as user daemon
17: without a password and /bin/ls as root with a password.
18:
19: As of sudo 1.6, the same line now means that millert is able
20: to run run both /usr/bin/whoami and /bin/ls as user daemon
21: without a password. To expand on this, take the following
22: example:
23:
24: millert ALL=(daemon) NOPASSWD:/usr/bin/whoami, (root) /bin/ls, \
25: /sbin/dump
26:
27: millert can run /usr/bin/whoami as daemon and /bin/ls and
28: /sbin/dump as root. No password need be given for either
29: command. In other words, the "(root)" sets the default runas
30: user to root for the rest of the list. If we wanted to require
31: a password for /bin/ls and /sbin/dump the line could be written
32: thusly:
33:
34: millert ALL=(daemon) NOPASSWD:/usr/bin/whoami, \
35: (root) PASSWD:/bin/ls, /sbin/dump
36:
37: Additionally, sudo now uses a per-user timestamp directory
38: instead of a timestamp file. This allows tty timestamps to
39: simply be files within the user's timestamp dir. For the
40: default, non-tty case, the timestamp on the directory itself
41: is used.
42:
43: Also, the temporary file used by visudo is now /etc/sudoers.tmp
44: since some versions of vipw on systems with shadow passwords use
45: /etc/stmp for the temporary shadow file.
46:
47: o Upgrading from a version prior to 1.5:
48:
49: By default, sudo expects the sudoers file to be mode 0440 and
50: to be owned by user and group 0. This differs from version 1.4
51: and below which expected the sudoers file to be mode 0400 and
52: to be owned by root. Doing a `make install' will set the sudoers
53: file to the new mode and group. If sudo encounters a sudoers
54: file with the old permissions it will attempt to update it to
55: the new scheme. You cannot, however, use a sudoers file with
56: the new permissions with an old sudo binary. It is suggested
57: that if have a means of distributing sudo you distribute the
58: new binaries first, then the new sudoers file (or you can leave
59: sudoers as is and sudo will fix the permissions itself as long
60: as sudoers is on a local filesystem).