o Make comment match reality, synch code with comment.

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
This commit is contained in:
Robert Watson 2000-11-30 23:14:55 +00:00
parent 88cd46c4d3
commit e292984cd3
Notes: svn2git 2020-12-20 02:59:44 +00:00
svn path=/head/; revision=69427

View file

@ -335,8 +335,16 @@ main(argc, argv)
(void)setpriority(PRIO_PROCESS, 0, prio);
#ifdef LOGIN_CAP
/* Set everything now except the environment & umask */
setwhat = LOGIN_SETUSER|LOGIN_SETGROUP|LOGIN_SETRESOURCES|LOGIN_SETPRIORITY;
/*
* Set all user context except for:
* Environmental variables
* Umask
* Login records (wtmp, etc)
* Path
*/
setwhat = LOGIN_SETALL & ~(LOGIN_SETENV | LOGIN_SETUMASK |
LOGIN_SETLOGIN | LOGIN_SETPATH);
/*
* Don't touch resource/priority settings if -m has been
* used or -l and -c hasn't, and we're not su'ing to root.