Please provide additional information, such as a traceback, that shows the crash point.

I got a similar crash; ABRT refused to add my details automatically, claiming that it was a dup of this already-closed bug, but I think it might be worth reopening based on the details I'm including from my abrt.log attempt at reporting the crash:

Count: 1
DUPHASH: c6647ca3
DumpDir: /var/cache/abrt/pyhook-1270819165-2444
Reported: 0
UUID: c6647ca3
analyzer: Python
architecture: i686
cmdline: /usr/bin/python /usr/sbin/bootconf
comment: It would be nicer if bootconf could print a useful message recommending that it be rerun with root privileges.
component: bootconf
executable: /usr/sbin/bootconf
kernel: 2.6.32.10-90.fc12.i686
package: bootconf-1.3-4.fc12
reason: bootconf:99:getconfig:IOError: [Errno 13] Permission denied: '/boot/grub/grub.conf'
release: Fedora release 12 (Constantine)
time: 1270819165
uid: 500

backtrace
-----
bootconf:99:getconfig:IOError: [Errno 13] Permission denied: '/boot/grub/grub.conf'

Traceback (most recent call last):
  File "/usr/sbin/bootconf", line 317, in <module>
    c=getconfig()
  File "/usr/sbin/bootconf", line 99, in getconfig
    f=open(configfile, "r")
IOError: [Errno 13] Permission denied: '/boot/grub/grub.conf'

Local variables in innermost frame:

description
-----
GRUB configuration utility

The bootconf configuration utility is a convenient tool for setting
GRUB kernel boot options.

reproduce
-----
1. run bootconf as non-root

How did you end up invoking /usr/sbin/bootconf directly?

The .desktop file installed by bootconf-gui explicitly runs /usr/bin/bootconf.

/usr/bin/bootconf is a symlink to consolehelper, which prompts for the root password, then invokes /usr/sbin/bootconf, as root.

It's a bug if you can find out exactly how you got /usr/sbin/bootconf invoked by non-root from the Gnome desktop. I don't see how that's possible.

There are two packages - bootconf and bootconf-gui.  If you install _only_ bootconf, then only /usr/sbin/bootconf is available (bootconf does not depend on bootconf-gui, which is a good thing in my mind).  And if you happen to have /usr/sbin on $PATH (even if /usr/bin comes first), then that explains how it happened to my non-root account.

I see plenty of stuff in /usr/sbin that won't work unless you're root, and which simply report the resulting errors without making any explicit checks, and emitting a pretty error message telling you to run it, as root. Example:

$ tcpdump -i eth0
tcpdump: eth0: You don't have permission to capture on that device
(socket: Operation not permitted)

I'm trying to understand why this is different. The same thing happens to bootconf -- it reports that it can't open a file that you need to be root, to access.

I think the issue here is that a python script terminating with a traceback is automatically assumed to always be a result of an internal bug or a crash.

I'll admit that my exposure to python is not very extensive, but on more familiar territory -- namely C++, Java, and Perl -- throwing an exception is a common, ordinary mechanism for reporting ordinary application errors. It happens all the time. An application terminated by a traceback should not always be assumed to be a bug.

But, it's certainly reasonable to add an explicit check for a root user. I'll put it in a post-F13 update.

Reopening for an F-13 update

bootconf-1.4-1.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/bootconf-1.4-1.fc13

bootconf-1.4-1.fc13 has been pushed to the Fedora 13 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update bootconf'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/bootconf-1.4-1.fc13

bootconf-1.4-1.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.