Red Hat Bugzilla – Bug 798686
Permission problem in xfce related to bug 693152
Last modified: 2013-02-13 21:30:41 EST
Description of problem:
Flash stick cannot be mounted as user (not root): cause "Not authorized" error dialog. Firewall util not asks for password, show error dialog "org.fedoraproject.slip.dbus.service.PolKit.NotAuthorizedException.org.fedoraproject.config.firewall.auth" and exit. PRM's cannot be installed by user, package manager don't asks for password just shows "Not authorized" error dialog. Etc. Just like bug 693152. I see what bug 693152 marked as fixed but guys it's not fixed.
Version-Release number of selected component (if applicable): 4.8.2
I just download dvd iso Fedora 16 x86_64 and install system.
Steps to Reproduce:
1. download dvd iso Fedora 16 x86_64
2. install system
3. switch to runlevel 3
5. start xfce by executing command $startxfce4
6. plug in flash stick
7. try to double click on flash stick icon what appears on desktop
'Not authorized' error dialog
Flash stick opens in file manager
You should not start Xfce like this. ;)
Instead of doing 'startxfce4', if you instead do:
- Create a ~/.xinitrc file with:
- chmod 755 ~/.xinitrc
Does everything work?
BTW I've downloaded iso again and check md5 checksum for new .iso and my old installation .iso - it's same. First I thought what my .iso is out of date, but it's not.
ok, from the failing session can you provide output of:
Here it is:
unix-user = '1000'
realname = 'ml'
seat = 'Seat1'
session-type = ''
active = FALSE
x11-display = ''
x11-display-device = ''
display-device = '/dev/tty1'
remote-host-name = ''
is-local = TRUE
on-since = '2012-03-02T07:59:31.644661Z'
login-session-id = '1'
idle-since-hint = '2012-03-02T08:00:05.556965Z'
The "active = FALSE" sounds like a problem.
If you boot in graphical mode and login via gdm does it work as expected?
Yes! It's works! I just login via GDM and choose Xfce session in session menu. Thank you so much, Kevin.
I still need a way to automatically login into xface from terminal but here is not right place for such discussion I guess.
Hmmm. On my second PC it doesn't helps. Session still inactive :(
So, looks like startx is not properly registering with consolekit somehow.
Moving over that component to see if there were any recent changes that could explain this.
Well there was this:
Author: Adam Jackson <firstname.lastname@example.org>
Date: Wed Nov 16 10:13:28 2011 -0500
Drop ConsoleKit integration, being removed in F17
I guess that wants reverting. Sigh. So much for "ConsoleKit removal", eh.
However, that doesn't really explain F16 being broken, since that change is only on the F17 and later branches.
Please drop the ConsoleKit stuff again, it must not be pulled-in by anything
like X in Fedora 17.
The desktop environments need to be fixed to work without Consolekit, or
they need to pull-in ConsoleKit, not ConsoleKit cludge pinned by X to make
other packages working. That is a really backwards logic.
I think we could look at subpackaging somehow here.
Surely gnome/kde don't call 'startx' or 'xinit' do they?
We can have xinit/startx dep on consolekit, and leave the rest alone?
ajax: should we discuss a better way of adjusting F17 in this bug, or should we file a new bug so as not to lose the f16 bug, which is likely something different?
Fedora Bugzappers volunteer triage team
gdm/kdm generally need the infrastructure bits from /etc/X11/, so 2 options:
1. put those bits in (something like) xorg-x11-xinit-common which can be Requires'd by xorg-x11-xinit, kdm, gdm, and friends
2. split out /usr/bin/ck-xinit-session (which has a separate Source anyway), into some subpkg, which non gdm/kdm DE's can depend on
Lennart notes on IRC:
<mezcalero> note that device access control in F16 already was not CK's business
so on F16 already startx was borked in this regard
dropping CK support from startx doesn't change anything effectively
That explains why this bug is against F16. It also means that re-adding the CK dep doesn't actually achieve anything.
Fedora Bugzappers volunteer triage team
This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 16. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '16'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 16's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 16 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora, you are encouraged to click on
"Clone This Bug" and open it against that version of Fedora.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.