$ su
% kill -STOP $$
where su is executing (t)csh. csh's job handling is a little more
special than that of (a)sh, bash and even zsh and blows up a little
more spectacularly. This modification restores the original mucking
about with the tty pgrp, but is careful to only do it when su (or
su's child) is the foreground process.
While I'm here, fix a STDERR_FILENO spelling as suggested by bde.
su isn't the foreground process. Hopefully this won't break PAM,
but I couldn't find any useful information about ache's theory
that it will.
Specifically, this change fixes the following:
# sh
# echo $$
# su - root -c id &
# echo $$
The PID output changes as su seems to be kill -STOP'ing itself
and catching the parent shell in the process. This is especially
bad if you add a ``su - user -c command &'' to an rc script!
Sponsored by: Sophos/Activestate
Not objected to by: des
the user indicating that su is not running setuid, which may help
suggest to the user that it should be setuid, or should not be
running from a file system mounted nosuid.
Suggsted by: Ivan Voras <ivoras at fer dot hr>
MFC after: 2 weeks
normally succeed (because root can su to anyone), but pam_acct_mgmt()
will most likely fail, causing su to log a confusing "pam_acct_mgmt:
error in service module" message. To avoid this, call getpwnam()
before pam_acct_mgmt().
Sponsored by: registrar.no
sometimes, su will receive a SIGTTOU when parent su tries to set child
su's process group as foreground group, and su will be stopped unexpectly,
ignoring SIGTTOU fixes the problem.
Noticed by: fjoe
- if operating "as them" (su -l), use pam_{open,close}_session()
- allow PAM to override $HOME (pam_chroot needs this)
- chdir early, because later on we may be chrooted and chdir will fail
Also use pid_t instead of int where applicable.
signal never affects su directly, some shells changes its pgrp at running
or suspended time, so a broadcast SIGTSTP from child will mess up su's job
control.
Discussed with: bde
also set the user's MAC label as part of the user credential setup
by setting setusercontext(3)'s SETMAC flag. By default, change only
traditional process properties.
Approved by: re
Obtained from: TrustedBSD Project
Sponsored by: DARPA, Network Associates Laboratories
kill login shell on either "suspend/fg" or "stop $$/fg" for tcsh. Since
this bug occurse on -stable too, it is not kernel threads bug.
Submitted by: David Xu <bsddiy@yahoo.com>
(see 'zsh exits upon ^C' thread). This may be temporary be he's been
running it for a year without incident so we should be golden with it.
Approved by: des
The remaining problem of converting highly incompatible pointer types
is done by "laundering" the value through a union.
This solves the problem (in my own mind) of how a "const char *" _ever_
actually gets a value in a WARNS=2 world.
for authentication to PAM. This meens that WHEELSU-type logic can
now be effected in the pam.conf "su" configuration stack. While here,
clean up the mess that the code had assumed over years of hacking by
folks using different styles. ANSIfy.
There is more policy in here that can be handed over to PAM. This will
be revisited.
The PAM_FAIL_CHECK and PAM_END macros in su.c came from the util-linux
package's PAM patches to the BSD login.c
Submitted by: "David J. MacKenzie" <djm@web.us.uu.net>
o In practice: the comment indicates that all but umask and
environmental variables of the users login class are applied when su
occurs, unless -m is used to specify a class. This was incorrect;
in practice, the uid, gids, resources, and priority were set, and
then resources and priority were selectively removed. This meant
that some aspects of the user context were not set, including handling
of login events (wtmp, utmp), as well as the path specified in
login.conf.
o I changed it so that the behavior is the same, but instead,
LOGIN_SETALL is used, and appropriate flags are removed, including
the LOGIN_SETLOGIN and LOGIN_SETPATH entries that were implicitly
not present before. I also updated the comment to reflect
reality, selecting reality as the "correct" behavior.
o This has the practical benefit that as new LOGIN_SET* flags are
introduced, they are supported by su unless specifically disabled.
For example, of a LOGIN_SETLABEL flag is introduced to support
MAC labels determined by the user's login class, then su no longer
has to be modified.
o It might be desirable to have su use LOGIN_SETPATH depending on
its command line parameters, as it might or might not be
considered part of the "environment".
Obtained from: TrustedBSD Project
