-17/Jan/99 1.5.8 1
+26/Jan/99 1.5.8 1
s\bs\bs\bsu\bu\bu\bud\bd\bd\bdo\bo\bo\bo tries to be safe when executing external commands.
Variables that control how dynamic loading and binding is
done can be used to subvert the program that s\bs\bs\bsu\bu\bu\bud\bd\bd\bdo\bo\bo\bo runs.
- To combat this the LD_*, SHLIB_PATH (HP-UX only), LIBPATH
- (AIX only), and _RLD_* environment variables are removed
+ To combat this the LD_*, _RLD_*, SHLIB_PATH (HP-UX only),
+ and LIBPATH (AIX only) environment variables are removed
from the environment passed on to all commands executed.
- s\bs\bs\bsu\bu\bu\bud\bd\bd\bdo\bo\bo\bo will also remove the IFS, ENV, BASH_ENV and KRB_CONF
- variables as they too can pose a threat.
+ s\bs\bs\bsu\bu\bu\bud\bd\bd\bdo\bo\bo\bo will also remove the IFS, ENV, BASH_ENV, KRB_CONF and
+ KRB5_CONFIG variables as they too can pose a threat.
-17/Jan/99 1.5.8 2
+26/Jan/99 1.5.8 2
sudo will not honor timestamp files set far in the future.
Timestamp files with a date greater than current_time + 2
- * TIMEOUT will be ignored and sudo will log the anomaly.
- This is done to keep a user from creating his/her own
- timestamp file with a bogus date.
+ * TIMEOUT will be ignored and sudo complain about a
+ "preposterous stampfile date". This is done to keep a
+ user from creating his/her own timestamp file with a bogus
+ date.
F\bF\bF\bFI\bI\bI\bIL\bL\bL\bLE\bE\bE\bES\bS\bS\bS
/etc/sudoers file of authorized users.
-
-17/Jan/99 1.5.8 3
+26/Jan/99 1.5.8 3
-17/Jan/99 1.5.8 4
+26/Jan/99 1.5.8 4
-17/Jan/99 1.5.8 5
+26/Jan/99 1.5.8 5
''' $RCSfile$$Revision$$Date$
'''
''' $Log$
-''' Revision 1.27 1999/01/17 22:40:53 millert
-''' crank version and regen files
+''' Revision 1.28 1999/02/01 00:45:02 millert
+''' clarify bad timestamp and fmt
'''
'''
.de Sh
.nr % 0
.rr F
.\}
-.TH sudo 8 "1.5.8" "17/Jan/99" "MAINTENANCE COMMANDS"
+.TH sudo 8 "1.5.8" "26/Jan/99" "MAINTENANCE COMMANDS"
.UC
.if n .hy 0
.if n .na
line arguments. It is most useful in conjunction with the \f(CW-s\fR flag.
.SH "RETURN VALUES"
\fBsudo\fR quits with an exit value of 1 if there is a
-configuration/permission problem or if \fBsudo\fR cannot execute
-the given command. In the latter case the error string is
-printed to stderr via \fIperror\fR\|(3). If \fBsudo\fR cannot \fIstat\fR\|(2)
-one or more entries in the user's PATH the error is printed
-on stderr via \fIperror\fR\|(3). (If the directory does not exist
-or if it is not really a directory, the entry is ignored and
-no error is printed.) This should not happen under normal
-circumstances. The most common reason for \fIstat\fR\|(3) to return
-\*(L"permission denied\*(R" is if you are running an automounter and
-one of the directories in your PATH is on a machine that is
-currently unreachable.
+configuration/permission problem or if \fBsudo\fR cannot execute the
+given command. In the latter case the error string is printed to
+stderr via \fIperror\fR\|(3). If \fBsudo\fR cannot \fIstat\fR\|(2) one or more entries
+in the user's PATH the error is printed on stderr via \fIperror\fR\|(3).
+(If the directory does not exist or if it is not really a directory,
+the entry is ignored and no error is printed.) This should not
+happen under normal circumstances. The most common reason for
+\fIstat\fR\|(3) to return \*(L"permission denied\*(R" is if you are running an
+automounter and one of the directories in your PATH is on a machine
+that is currently unreachable.
.SH "SECURITY NOTES"
-\fBsudo\fR tries to be safe when executing external commands.
-Variables that control how dynamic loading and binding is
-done can be used to subvert the program that \fBsudo\fR runs.
-To combat this the \f(CWLD_*\fR, \f(CWSHLIB_PATH\fR (HP\-UX only),
-\f(CWLIBPATH\fR (AIX only), and \f(CW_RLD_*\fR environment variables are
-removed from the environment passed on to all commands executed.
-\fBsudo\fR will also remove the \f(CWIFS\fR, \f(CWENV\fR, \f(CWBASH_ENV\fR
-and \f(CWKRB_CONF\fR variables as they too can pose a threat.
+\fBsudo\fR tries to be safe when executing external commands. Variables
+that control how dynamic loading and binding is done can be used
+to subvert the program that \fBsudo\fR runs. To combat this the
+\f(CWLD_*\fR, \f(CW_RLD_*\fR, \f(CWSHLIB_PATH\fR (HP\-UX only), and \f(CWLIBPATH\fR (AIX
+only) environment variables are removed from the environment passed
+on to all commands executed. \fBsudo\fR will also remove the \f(CWIFS\fR,
+\f(CWENV\fR, \f(CWBASH_ENV\fR, \f(CWKRB_CONF\fR and \f(CWKRB5_CONFIG\fR variables as
+they too can pose a threat.
.PP
-To prevent command spoofing, \fBsudo\fR checks "." and "" (both
-denoting current directory) last when searching for a command
-in the user's PATH (if one or both are in the PATH).
-Note, however, that the actual PATH environment variable
-is \fInot\fR modified and is passed unchanged to the program that
-\fBsudo\fR executes.
+To prevent command spoofing, \fBsudo\fR checks "." and "" (both denoting
+current directory) last when searching for a command in the user's
+PATH (if one or both are in the PATH). Note, however, that the
+actual PATH environment variable is \fInot\fR modified and is passed
+unchanged to the program that \fBsudo\fR executes.
.PP
-For security reasons, if your OS supports shared libraries,
-\fBsudo\fR should always be statically linked unless the
-dynamic loader disables user-defined library search paths
-for setuid programs. (Most modern dynamic loaders do this.)
+For security reasons, if your OS supports shared libraries, \fBsudo\fR
+should always be statically linked unless the dynamic loader disables
+user-defined library search paths for setuid programs. (Most modern
+dynamic loaders do this.)
.PP
\fBsudo\fR will check the ownership of its timestamp directory
-(\fI/var/run/sudo\fR or \fI/tmp/.odus\fR by default) and ignore
-the directory's contents if it is not owned by root and
-only read, writable, and executable by root. On systems
-that allow users to give files away to root (via chown),
-if the timestamp directory is located in a directory writable
-by anyone (ie: \fI/tmp\fR), it is possible for a user to create
-the timestamp directory before \fBsudo\fR is run.
-However, because \fBsudo\fR checks the ownership and mode of
-the directory, the only damage that can be done is to \*(L"hide\*(R"
-files by putting them in the timestamp dir. This is unlikely
-to happen since once the timestamp dir is owned by root and
-inaccessible by any other user the user placing files there
-would be unable to get them back out. To get around this
-issue you can use a directory that is not world-writable
-for the timestamps (\fI/var/adm/sudo\fR for instance).
+(\fI/var/run/sudo\fR or \fI/tmp/.odus\fR by default) and ignore the
+directory's contents if it is not owned by root and only read,
+writable, and executable by root. On systems that allow users to
+give files away to root (via chown), if the timestamp directory is
+located in a directory writable by anyone (ie: \fI/tmp\fR), it is
+possible for a user to create the timestamp directory before \fBsudo\fR
+is run. However, because \fBsudo\fR checks the ownership and mode of
+the directory, the only damage that can be done is to \*(L"hide\*(R" files
+by putting them in the timestamp dir. This is unlikely to happen
+since once the timestamp dir is owned by root and inaccessible by
+any other user the user placing files there would be unable to get
+them back out. To get around this issue you can use a directory
+that is not world-writable for the timestamps (\fI/var/adm/sudo\fR for
+instance).
.PP
-\f(CWsudo\fR will not honor timestamp files set far in the
-future. Timestamp files with a date greater than
-current_time + 2 * \f(CWTIMEOUT\fR will be ignored and
-sudo will log the anomaly. This is done to keep a user
-from creating his/her own timestamp file with a bogus
-date.
+\f(CWsudo\fR will not honor timestamp files set far in the future.
+Timestamp files with a date greater than current_time + 2 * \f(CWTIMEOUT\fR
+will be ignored and sudo complain about a \*(L"preposterous stampfile
+date\*(R". This is done to keep a user from creating his/her own
+timestamp file with a bogus date.
.SH "FILES"
.PP
.Vb 1
=head1 RETURN VALUES
B<sudo> quits with an exit value of 1 if there is a
-configuration/permission problem or if B<sudo> cannot execute
-the given command. In the latter case the error string is
-printed to stderr via perror(3). If B<sudo> cannot stat(2)
-one or more entries in the user's PATH the error is printed
-on stderr via perror(3). (If the directory does not exist
-or if it is not really a directory, the entry is ignored and
-no error is printed.) This should not happen under normal
-circumstances. The most common reason for stat(3) to return
-"permission denied" is if you are running an automounter and
-one of the directories in your PATH is on a machine that is
-currently unreachable.
+configuration/permission problem or if B<sudo> cannot execute the
+given command. In the latter case the error string is printed to
+stderr via perror(3). If B<sudo> cannot stat(2) one or more entries
+in the user's PATH the error is printed on stderr via perror(3).
+(If the directory does not exist or if it is not really a directory,
+the entry is ignored and no error is printed.) This should not
+happen under normal circumstances. The most common reason for
+stat(3) to return "permission denied" is if you are running an
+automounter and one of the directories in your PATH is on a machine
+that is currently unreachable.
=head1 SECURITY NOTES
-B<sudo> tries to be safe when executing external commands.
-Variables that control how dynamic loading and binding is
-done can be used to subvert the program that B<sudo> runs.
-To combat this the C<LD_*>, C<SHLIB_PATH> (HP-UX only),
-C<LIBPATH> (AIX only), and C<_RLD_*> environment variables are
-removed from the environment passed on to all commands executed.
-B<sudo> will also remove the C<IFS>, C<ENV>, C<BASH_ENV>
-and C<KRB_CONF> variables as they too can pose a threat.
-
-To prevent command spoofing, B<sudo> checks "." and "" (both
-denoting current directory) last when searching for a command
-in the user's PATH (if one or both are in the PATH).
-Note, however, that the actual PATH environment variable
-is I<not> modified and is passed unchanged to the program that
-B<sudo> executes.
-
-For security reasons, if your OS supports shared libraries,
-B<sudo> should always be statically linked unless the
-dynamic loader disables user-defined library search paths
-for setuid programs. (Most modern dynamic loaders do this.)
+B<sudo> tries to be safe when executing external commands. Variables
+that control how dynamic loading and binding is done can be used
+to subvert the program that B<sudo> runs. To combat this the
+C<LD_*>, C<_RLD_*>, C<SHLIB_PATH> (HP-UX only), and C<LIBPATH> (AIX
+only) environment variables are removed from the environment passed
+on to all commands executed. B<sudo> will also remove the C<IFS>,
+C<ENV>, C<BASH_ENV>, C<KRB_CONF> and C<KRB5_CONFIG> variables as
+they too can pose a threat.
+
+To prevent command spoofing, B<sudo> checks "." and "" (both denoting
+current directory) last when searching for a command in the user's
+PATH (if one or both are in the PATH). Note, however, that the
+actual PATH environment variable is I<not> modified and is passed
+unchanged to the program that B<sudo> executes.
+
+For security reasons, if your OS supports shared libraries, B<sudo>
+should always be statically linked unless the dynamic loader disables
+user-defined library search paths for setuid programs. (Most modern
+dynamic loaders do this.)
B<sudo> will check the ownership of its timestamp directory
-(F</var/run/sudo> or F</tmp/.odus> by default) and ignore
-the directory's contents if it is not owned by root and
-only read, writable, and executable by root. On systems
-that allow users to give files away to root (via chown),
-if the timestamp directory is located in a directory writable
-by anyone (ie: F</tmp>), it is possible for a user to create
-the timestamp directory before B<sudo> is run.
-However, because B<sudo> checks the ownership and mode of
-the directory, the only damage that can be done is to "hide"
-files by putting them in the timestamp dir. This is unlikely
-to happen since once the timestamp dir is owned by root and
-inaccessible by any other user the user placing files there
-would be unable to get them back out. To get around this
-issue you can use a directory that is not world-writable
-for the timestamps (F</var/adm/sudo> for instance).
-
-C<sudo> will not honor timestamp files set far in the
-future. Timestamp files with a date greater than
-current_time + 2 * C<TIMEOUT> will be ignored and
-sudo will log the anomaly. This is done to keep a user
-from creating his/her own timestamp file with a bogus
-date.
+(F</var/run/sudo> or F</tmp/.odus> by default) and ignore the
+directory's contents if it is not owned by root and only read,
+writable, and executable by root. On systems that allow users to
+give files away to root (via chown), if the timestamp directory is
+located in a directory writable by anyone (ie: F</tmp>), it is
+possible for a user to create the timestamp directory before B<sudo>
+is run. However, because B<sudo> checks the ownership and mode of
+the directory, the only damage that can be done is to "hide" files
+by putting them in the timestamp dir. This is unlikely to happen
+since once the timestamp dir is owned by root and inaccessible by
+any other user the user placing files there would be unable to get
+them back out. To get around this issue you can use a directory
+that is not world-writable for the timestamps (F</var/adm/sudo> for
+instance).
+
+C<sudo> will not honor timestamp files set far in the future.
+Timestamp files with a date greater than current_time + 2 * C<TIMEOUT>
+will be ignored and sudo complain about a "preposterous stampfile
+date". This is done to keep a user from creating his/her own
+timestamp file with a bogus date.
=head1 FILES
projects / sudo / commitdiff