> >>You should never send an unencrypted password over a shell or pipe.

So in the case of the former (using the shell, via echo or an
environment variable) you are correct. Those show up in process
listings...

I am not so sure about the second part, the bit about not passing
confidential information down a pipe. I am not aware of a third
party being able to see the content of a pipe. If you are worried
about the invoking user seeing the password, bear in mind that on sane
distributions a normal user can strace the xterm in which one
invokes su or sudo. This is not a recommendation to disable
strace, it is a strong recommendation to run your webbrowser
under a different uid - actually I am surprised that distributions
dont have a wrapper which runs a browser as a different uid
but with a shared gid...

> i would use a simple gtk window with a gtkentry (Gtk2 GTK3 compatible) + 2 buttons (cancel, ok)
> that way it will be the gtk backend to care about X11 or wayland (i suppose...):
...
> Why use 2 binaries rather than one, more programs, more code, more communication in between them equals to more attack surface.
> I would stay with just one suid binary, more so if you want to go the su-only route.

If I understand you correctly, you propose a simple gtk
program that is setuid (so that it can read /etc/shadow, and
grant root privileges). The problem is that there is no such
thing as a simple gtk program. This is not comment limited to
gtk programs - most graphical toolkits and libraries present
a pretty large attack surface - they contain large protocol
interpreters and font rendering engines, flaws in which could
then be exploited to give root access without any password
whatsoever.

So invoking su or sudo via a pipe is probably the way to go
after all. Do note that sudo (or su) might not accept input
from a plain pipe - you might have to allocate a pseudotty
via /dev/pts/ptmx, then fork, exec su or sudo in the child
and in the parent write the password down the filedescriptor...

regards

marc