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 328911 - beagled script needs fixes
beagled script needs fixes
Status: RESOLVED FIXED
Product: beagle
Classification: Other
Component: General
0.2.0
Other Linux
: Normal normal
: ---
Assigned To: Beagle Bugs
Beagle Bugs
Depends on:
Blocks:
 
 
Reported: 2006-01-27 23:38 UTC by Christopher Aillon
Modified: 2006-03-22 22:34 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Committed this patch (16.04 KB, patch)
2006-03-22 20:39 UTC, Joe Shaw
committed Details | Review
Updated patch; the last one was a little broken. (14.45 KB, patch)
2006-03-22 22:34 UTC, Joe Shaw
committed Details | Review

Description Christopher Aillon 2006-01-27 23:38:29 UTC
Upstreaming from: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177675

a) it runs programs in the current directory rather than the installed app if it
finds them
b) its error reporting if the daemon exits (for something launched via the
session!) is to echo to stdout
Comment 1 Joe Shaw 2006-01-30 20:08:38 UTC
a) is by design, so that developers can run out of the source directory.

b) is an unlikely occurrance, because the daemon is generally run "exec".  But if for some reason the daemon is running in background mode and exits early, it prints an error.  I've added an "exit 1" to that case.

This is fixed now in CVS.
Comment 2 Christopher Aillon 2006-01-30 22:56:13 UTC
a) is a security flaw if a user writes those files to /tmp and gets another user to run f-spot while in /tmp.  Maybe you should wrap it around an environment variable or something such as DOING_BEAGLE_DEVELOPMENT, but it cannot be unchecked.

Reopening to fix a)
Comment 3 Christopher Aillon 2006-01-30 22:57:53 UTC
er, i obviously meant "gets another user to run beagle while in /tmp"
Comment 4 Debajyoti Bera 2006-01-31 04:30:44 UTC
I dont quite understand. If another user runs beagled from /tmp, beagled will only access files legally accessible by the user.

I have a faint sense of another meaning: do you mean in beagle-search (GUI), when the applications are executed, they are executed from current-directory - which can be a security flaw ?
Comment 5 Christopher Aillon 2006-01-31 04:47:41 UTC
No...

Attacker creates an f-spot.exe which does something evil such as mail the victim's private SSH keys to the attacker and places it in /tmp, and chmods it 777.  Attacker also touches Makefile and Defines.cs.  If the victim happens to type /usr/bin/f-spot or simply f-spot from a console while in /tmp, then the evil f-spot.exe is activated.
Comment 6 Christopher Aillon 2006-01-31 04:49:39 UTC
(and gah, apologies.  I keep looking at f-spot's script for some reason instead of beagle ... it has the same exact issue though).
Comment 7 Joe Shaw 2006-01-31 19:52:11 UTC
Ok, at the top of beagled.in, there's a line like this:

if [ -e ./@target@ ] && [ -e ./Makefile.am ] ; then

If I changed this to be:

if [ `pwd` = "@srcdir@"]; then

where @srcdir@ is set to `pwd` at compile-time, would that be sufficiently safe?
Comment 8 Christopher Aillon 2006-02-07 21:07:22 UTC
That's still a bit broken.  Installing something for developers only into a place where normal users can potentially break it is always a bad idea.  Can we simply not even ship that part of the wrapper unless a compile flag is set (--enable-maintainer-mode)?
Comment 9 Joe Shaw 2006-03-22 20:39:56 UTC
Created attachment 61791 [details] [review]
Committed this patch
Comment 10 Joe Shaw 2006-03-22 22:34:24 UTC
Created attachment 61802 [details] [review]
Updated patch; the last one was  a little broken.