Bug List: (This bug is not in your last search results)   Show last search results      Search page      Enter new bug
Bug#: 160132
Alias:
Product:
Component:
Status: RESOLVED
Resolution: FIXED
Assigned To: Gentoo Security <security@gentoo.org>
Hardware:
OS:
Version:
Priority:
Severity:
Reporter: Vic Fryzel (shellsage) (RETIRED) <shellsage@gentoo.org>
Add CC:
CC:
Remove selected CCs
URL:
Summary:
Status Whiteboard:
Keywords:
Flags: Requestee:
 
 
  ()

Filename Description Type Creator Created Size Actions
Create a New Attachment (proposed patch, testcase, etc.) View All

Bug 160132 depends on: Show dependency tree
Bug 160132 blocks:

Additional Comments: (this is where you put emerge --info)


Not eligible to see or edit group visibility for this bug.






View Bug Activity   |   Format For Printing   |   XML   |   Clone This Bug


Description:   Opened: 2007-01-04 15:58 0000
The x11-misc/adesklets specifies a location in /tmp for log storage.  An
attacker could create the file /tmp/adesklets_log.pid* as a symlink to
arbitrary files on the system, and possibly overwrite those files, upon
adesklets filing a log entry. The ebuild should specify a log location that is
not in a world accessible directory.

------- Comment #1 From Sune Kloppenborg Jeppesen 2007-01-06 12:58:08 0000 -------
s4t4n please advise.

------- Comment #2 From Michele Noberasco 2007-01-07 08:21:29 0000 -------
Well, adesklets runs with the privileges of the user who launched it, so this
would be an issue only if that user is root (silly thing)...
Also, this log file gets created only if debug is in USE.
Anyway, I just committed to Portage a small change to the ebuilds so that log
files are created in user home directories instead of /tmp; methinks it should
be enough.

------- Comment #3 From Michele Noberasco 2007-01-24 08:51:21 0000 -------
No feedback, closing. Feel free to reopen if necessary...

------- Comment #4 From Raphael Marichez 2007-02-10 20:56:17 0000 -------
(In reply to comment #3)
> No feedback, closing. Feel free to reopen if necessary...
> 


I agree. "INVALID" would even be appropriate.

Bug List: (This bug is not in your last search results)   Show last search results      Search page      Enter new bug