~ubuntu-branches/ubuntu/quantal/sudo/quantal

« back to all changes in this revision

Viewing changes to UPGRADE

  • Committer: Package Import Robot
  • Author(s): Marc Deslauriers
  • Date: 2011-11-20 12:07:45 UTC
  • mfrom: (1.3.17 sid)
  • Revision ID: package-import@ubuntu.com-20111120120745-o3qpklobmygytndc
Tags: 1.8.3p1-1ubuntu1
* Merge from debian/testing, remaining changes:
  - debian/patches/keep_home_by_default.patch:
    + Set HOME in initial_keepenv_table. (rebased for 1.8.3p1)
  - debian/patches/enable_badpass.patch: turn on "mail_badpass" by default:
    + attempting sudo without knowing a login password is as bad as not
      being listed in the sudoers file, especially if getting the password
      wrong means doing the access-check-email-notification never happens
      (rebased for 1.8.3p1)
  - debian/rules:
    + compile with --without-lecture --with-tty-tickets (Ubuntu specific)
    + install man/man8/sudo_root.8 (Ubuntu specific)
    + install apport hooks
    + The ubuntu-sudo-as-admin-successful.patch was taken upstream by
      Debian however it requires a --enable-admin-flag configure flag to
      actually enable it.
  - debian/sudoers: 
    + grant admin group sudo access
  - debian/sudo-ldap.dirs, debian/sudo.dirs: 
    + add usr/share/apport/package-hooks
  - debian/sudo.preinst:
    + avoid conffile prompt by checking for known default /etc/sudoers
      and if found installing the correct default /etc/sudoers file

Show diffs side-by-side

added added

removed removed

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