Hi Rainer, On Sat, Aug 29, 2015 at 3:48 PM, Rainer Weikusat <rainerweiku...@virginmedia.com> 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 _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
