RFD: patch: su: ignoring switches and continuing: --preserve-environment v. --login

[Linda Walsh <lkml@tlinx.org>]

> @@ -98,6 +98,7 @@ Preserves the whole environment, ie does not set
>  .B USER
>  nor
>  .BR LOGNAME .
> +The option is ignored if the option \fB\-\-login\fR is specified.
---
There are 2 problems
On the surface, this patch, alone, appears to remove desirable
functionality from su, and, it is a dangerous change in default
function to make to a previously existing command that may
be scripted.

I can easily see scripts that expect the environment to be preserved
after su/with login EXCEPT for things that would have to change
(like logname, UID EUID USER).

In the best case, I would like to see this semantic preserved, though
if not through the combined use of these switches, through an alternative
set of switches.

However, if someone thinks this functionality cannot be provided with
these switches and wants to move that functionality to a new set of
switches (or are they suggesting shipping a crippled 'su' that no
longer allows this?), then simply ignoring the "keep-env" and
executing a command would be dangerous if those commands rely on
information in ENV for proper execution.

To simply ignore 'keep', is the worse outcome -- because you don't want
a command that has likely just switched to root, to have ENV vars
it depends on destroyed.  If su is about to run a series of command --
maybe used with '-c' and quotes, and contains something like:

  -c 'bash -c '\''cd "${BUILDROOT}/" && find . -delete'\'''

If you ignore the keep-env, but continued execution as root then
such a command would wipe the system.

If you need break that functionality, then the combination of those
switches should NOT execute the subsequent command -- the command should
fail.

OTOH, one would ask how does one switch to a  new USER/LOGNAME while
keeping all the rest of their ENV intact, as is now possible?
Are you saying "we are shipping a new 'su' without this ability"?

Then I'd ask how is shipping an 'su' program without this flexibility
useful to the user base?   If a site policy wants to restrict this
usage, there are other ways to that, but we aren't talking the
"average user" -- we are talking about a facility that is only
usable by system-owners and admins -- i.e. people authorized to
use such a command.  Removing this functionality wouldn't impact
normal users who are not authorized to 'su' to another USERID
such as root (or whoever), but would only impact those who
design system-policy.  I would strongly the usefulness of such a
change.