Hi Rainer,

On Sat, Aug 29, 2015 at 3:48 PM, Rainer Weikusat
<rainerweikusat@???> wrote:
> 'su' is a somewhat generic setuid-0 program: It changes the uid and the
> gids associated with itself to the ones for a certain user and then
> executes a shell. In addition to that, it contains another "random
> environment munger" with features someone happend to consider useful for
> the su use cases he envisioned. If this happens to be what enables
> someone else to achieve something he wanted to achieve, 'su' can
> obviously be used for that. If not, then not. But the reason why su is
> only of limited usefulness is not because the hardcoded policy isn't
> complicated enough to include
>
> $random_thing_someone_called_lennart_also_wants
>
> for every conceivable value of the variable but because it has a
> hardcoded policy at all and the solution is not "implement another,
> random environment munger more to tastes of ..." but split it apart:

That is exactly what systemd implemented: The uid/gid gets changed and
then you get exactly the same environment that gets set up for you
during login. Nothing is merged, no munching of anything is happening
anymore.

> Have a program which changes uids and gids and executes another
> program. Another program for the become root via setuid and execute
> ... part. And a third program (or any number of such programs) to
> perform other modifications of the execution environment.

So you have to worry about users sneaking in a "muncher" (e.g. by
manipulating PATH, LD_PRELOAD or whatnot) that will be run with the
new uid/gid and can attack the user and system to its hearts content.
Very bad idea. Some things are not as dynamic as they could be for a
reason.

Best Regards,
Tobias