After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 570530 - Sockets are chown()ed to another user when running as root
Sockets are chown()ed to another user when running as root
Status: RESOLVED NOTABUG
Product: ORBit2
Classification: Deprecated
Component: general
2.14.x
Other Linux
: Normal critical
: ---
Assigned To: ORBit maintainers
ORBit maintainers
Depends on:
Blocks:
 
 
Reported: 2009-02-04 19:00 UTC by Josselin Mouette
Modified: 2009-02-05 10:15 UTC
See Also:
GNOME target: ---
GNOME version: 2.23/2.24

Attachments
Do not chown() a socket belonging to root (1.38 KB, patch)
2009-02-04 19:01 UTC, Josselin Mouette 		none Details | Review

Description Josselin Mouette 2009-02-04 19:00:24 UTC 
When starting an application as root using su (I know, that’s bad, but PolicyKit is still not the rule), it re-uses the $ORBIT_SOCKETDIR that is passed; that’s not much a problem in itself, since it allows nice things like re-using an existing GConf daemon.

However, the socket created by the application launched as root is chown()ed so that it belongs to the user $ORBIT_SOCKETDIR belongs to. This allows the said user to communicate with the root application, which means controlling it partly or entirely if it uses libbonobo.

This is very dangerous and this behavior should be removed ; I can’t even see a valid use case for it.
Comment 1 Josselin Mouette 2009-02-04 19:01:26 UTC 
Created attachment 127937 [details] [review]
Do not chown() a socket belonging to root
Comment 2 Michael Meeks 2009-02-05 10:15:44 UTC 
This is an accessibility feature.

How is an Accessibility Technology going to communicate with the application if it can't communicate, the gconf thing I guess is an unwanted but not unwelcome side-effect I suppose.

Also - please note, that as soon as the root owned X application connects to the X server, other non-root apps can start poking at the application in many of the same ways; oh - and of course gtk+ is not a 'secure' toolkit - so there are many levels of equivocation here.

If you want a 'secure' root run application, at the level you're talking about, here are some other things you might want to consider: not least that in typing 'su' you could have fallen victim to some credential stealing wrapper program ;-)

HTH.