Re: gksu: Couldn't set environment variable...
Raf Czlonka wrote:
> Bob Proulx wrote:
> > Sthu Deus wrote:
> > > I can not run two applications w/ gksu:
> > >
> > > chromium and
> > > qbittorrent
> >
> > Why do you want to run those applications as root? You should not do
> > this. Neither of those applications are designed for being run as
> > root. Those should be run as a normal non-root user.
>
> Sthu hadn't mentioned even once that he tries to run those as root.
Uhm... What? But he did! You must have missed that he said he
wanted to run them from gksu. If you are not familiar with it that is
the entire purpose of gksu. From the gksu man page:
gksu is a frontend to su and gksudo is a frontend to sudo. Their pri-
mary purpose is to run graphical commands that need root without the
need to run an X terminal emulator and using su directly.
Therefore, yes, he did say he wanted to run those as root. :-) :-)
> Nevertheless, in principle, I do agree with Bob here - IMHO, running
> standard software as root is a bit silly, to say the least.
> What I disagree with is the statement that they hadn't been designed
> to run as root. Root, UID 0, a special kind of user it might be, is
> still a user and can/should be able to run *any* program. The question
> "why" would anyone do that is a different matter altogether.
Large applications have hundreds of thousands of lines of code and
often have a bug or two in them. (No! They wouldn't, would they?)
Graphical applications fall into that category. The Chromium web
browser falls into that category. There is probably a bug in there.
I don't know of any particular bug but I could place a pretty safe
wager that there is a bug in there somewhere. The current version
crashes the sandbox with an "Aw, Snap!" crash for example.
Let's say a bug might be as simple such as leaving behind files in
your $HOME that are owned by root and not writable by any other user
and because they are in an unwritable subdirectory owned by root they
cannot be removed by the non-root user either. That would be typical
of one type of problem that often occurs in that situation of large
complicated programs run by root in your $HOME that weren't intended
to be run by root in your $HOME. Not to even mention other more
insidious problems.
Okay to mention more insidious problems, if the sandboxing isn't
perfect them it might be possible for a cracking attack to break out
and access the filesystem. If they access the filesystem as a
non-root user then they are still contained. But if the application
is run as root then they access the filesystem as root and there is no
containment. A lot of applications which are required to run as root
try very hard to drop their root privileges as soon as possible in
order to avoid those types of attacks. Since Chromium isn't designed
to be run that way it doesn't try to drop privileges and would be open
to being attacked in that way. That doesn't mean there *is* a hole.
It means there is less protection from it and it has historically been
a problem in other applications that were designed to run as root
which then decided that such protection was necessary. Look at
OpenSSH's privilege separation design for example.
Of course if the program to be run under gksu were Synaptic then that
would make perfect sense. Synaptic is a GUI and requires root and is
designed to be run as root. A perfect match for gksu (or apparently
the new policy kit layer) and no complaints from me about it.
Bob
Reply to: