+++ This bug was initially created as a clone of Bug #219279 +++ Description of problem: GConf uses the directory /tmp/gconfd-$LOGNAME for storing a lock file (and possibly some other stuff -- I do not know, I know nearly nothing about GConf) even if GCONF_GLOBAL_LOCKS environment is not set. As the /tmp directory is sticky, it is possible for any user to create the directory with this name prior to first login of a new user, effectively preventing it from using GConf clients. The impact of this is quite serious, as the user can't use most of Gnome, Evolution, etc. and it's quite hard for a non-technican user to work it around. Additionaly, I think any temporary directory and file should disappear when application terminates. It is obvious that it is not a good practice not to do so. Version-Release number of selected component (if applicable): At least FC5 and FC6's GConf. How reproducible: Before user logs in/launches GConfd for the first time. Some systems erase /tmp at each startup or use memory-based filesystem for it. In that case the problem is reproducible after each startup. Steps to Reproduce: This migh be obvious enough while (true); do touch /tmp/gconfd-$(tail -n1 /etc/passwd |awk -F: '{print $1}'); done
After discussion with Mark Cox, this is a low impact issue, doesn't have to block GA.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux major release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Major release. This request is not yet committed for inclusion.
as per comment 1, clearing GA flag
Hi, There are a few ways we could address this problem: 1) use the kernel user or session keyring to store the information we're currently storing in /tmp 2) make gconf get on the session bus, and export methods to get the information that's currently stored in /tmp 3) look up the session guid and name the directory based on the guid Of the available options, 3 is the least invasive, because it only involves looking at an environment variable. It's also not fool proof, it just makes the directory name harder to figure out. Long term, gconf is going to lose its orbit dependency entirely and use dbus for ipc between the client lib and session daemon. When that happens, this problem will solve itself. I talked this over a bit with Havoc today, and the consensus is that this issue isn't important enough to fix without sufficient customer interest. Any change carries a potential risk of breaking things associated with it, so we want to be careful what changes go in. Anyway, dev nacking for now.
Development Management has reviewed and declined this request. You may appeal this decision by reopening this request.
Why has a security flaw been automatically closed WONTFIX? In no way is this acceptable or responsible behavior.
Hi, So I talked to Josh about this a little bit today and the conclusion of the discussion is that I should give a little more explanation on why this bug is WONTFIXed and point out that WONTFIXing the bug is an explicit decision and not something that's just a side effect of flag churn. While fixing this problem wouldn't be technically difficult to do, it does come with an associated risk of regression. gconf plays a fairly integral part in presenting the user with a functional desktop, so changes made to it shouldn't be made lightly. While the issue pointed out in this bug is valid, fixing the issue probably doesn't outweigh the risk of the changing GConf. This holds even more true, because there is no customer interest. The standard response to these types of denial of service issues is the "don't do that" response. That is to say, it's not unreasonable to expect a sysadmin to resort to social discipline if an unruly user tries to do this type of thing. This also applies for things like fork() bombs, and using up all the disk space in /tmp for instance. This is something that should get addressed, but not for RHEL 5. If there was customer interest, we could provide a fix that is off by default and on with an environment variable or some such thing. Anyway, for now, the answer is WONTFIX.