Bug 820675 - startx does not work with systemd-logind
Summary: startx does not work with systemd-logind
Keywords:
Status: CLOSED DUPLICATE of bug 806491
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-xinit
Version: 17
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: X/OpenGL Maintenance List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 826459 827093 827727 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-05-10 16:24 UTC by Andrew
Modified: 2012-06-12 13:18 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-06-12 13:18:50 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Andrew 2012-05-10 16:24:35 UTC
Can't mount USB flash drive by either KDE Device Notifier applet or udisks command with following error:

$ udisks --mount /dev/sde1
Mount failed: Not Authorized

Root permissions fix this, but mount point isn't readable for users.

Note: I use runlevel 3 as default and such mounting by udisks works ok just after login in virtual console. It fails when launched from Konsole (KDE terminal emulator).
I'm not sure udisks is the reason, but I don't know more appropriate component.

Components versions:

kernel-3.3.4-3.fc17.x86_64
systemd-44-8.fc17.x86_64
udisks-1.0.4-6.fc17.x86_64

Comment 1 Robert Gadsdon 2012-05-25 09:42:29 UTC
---
Same problem with my (2) x86_64 systems, recently upgraded from FC16 (where everything worked OK..)

KDE device notifier recognises USB disks, but gives:

'could not mount the following device. 
 an unspecified error has occurred. 
 Not authorized'

error message.

and:

# udisks --mount /dev/sdl1
Mount failed: Not Authorized

- udisks mount works when run as root, but this leaves the directory inaccessible to users..:

# udisks --mount /dev/sdl1
Mounted /org/freedesktop/UDisks/devices/sdl1 at /media/USB3_DISK01

Tried installing _clean_ version of KDE, with new user account, but problem was still there..
Tried 'downgrading' to FC16 version of udisks (from rebuilt F16 source rpm), but no difference..
Tried different kernel versions (compiled)- no difference..
Tried mounting from Gnome3 desktop, but had to enter root password to get mount to work, and then the directory was inaccessible to users...

Other USB devices (scanner and camera) are recognised - and accessed - correctly..

kdelibs-4.8.3-1.fc17.x86_64
udisks-1.0.4-6.fc17.x86_64
kernel-3.3.6-3.fc17.x86_64

Robert Gadsdon.

Comment 2 Robert Gadsdon 2012-05-26 01:14:33 UTC
Additional info:

Selinux is disabled, on all systems..

Just reproduced problem on FC17 ARM system, as well (Raspberry Pi):

[rgadsdon@rgpi ~]$ uname -a
Linux rgpi 3.1.9 #1 Wed May 16 10:00:10 BST 2012 armv6l armv6l armv6l GNU/Linux
[rgadsdon@rgpi ~]$ udisks --mount /dev/sda1
Mount failed: Not Authorized

Robert Gadsdon

Comment 3 Robert Gadsdon 2012-05-27 14:12:24 UTC
Update:

Just installed clean/new version of Fedora 17 on a test system (VMware), and on that system, # udisks --mount ...  command _does_ work correctly, when running as normal user, from plain console session..    Only fails when running from X session, using KDE device-notifier or x-console command line..

Robert Gadsdon.

Comment 4 Sergio Basto 2012-05-28 02:59:56 UTC
(In reply to comment #3)
> Only fails when
> running from X session, using KDE device-notifier or x-console command line..
> 

yeah here the same problem lots of Not authorized in kde , on Fedora 17 
upgrade . 

udisks --mount /dev/sr0
Mount failed: Not Authorized

Comment 5 Robert Gadsdon 2012-05-28 08:59:40 UTC
A workaround was found at http://www.suurmeijer.net, and has been slightly modified:

Edit /usr/share/polkit-1/actions/org.freedesktop.udisks.policy as follows:

  <action id="org.freedesktop.udisks.filesystem-mount">
    <description>Mount a device</description>
    <description xml:lang="da">Montér en enhed</description>
    <message>Authentication is required to mount the device</message>
    <message xml:lang="da">Autorisering er påkrævet for at montere et fil system</message>
    <defaults>
      <allow_any>no</allow_any>
      <allow_inactive>yes</allow_inactive>
      <allow_active>yes</allow_active>
    </defaults>
  </action>

Change is 
from <allow_inactive>no</allow_inactive> 
to   <allow_inactive>yes</allow_inactive>

Applied these changes, and KDE USB mount now works.    It would appear that when starting a KDE session from the command line (# startx) the session is still flagged as 'inactive' for some reason...

Robert Gadsdon..

Comment 6 David Zeuthen 2012-05-29 14:30:15 UTC
Looks like a problem with KDE, not sure what component to reassign so just closing as WORKSFORME. If you find out what component it is, feel free to reopen and ressign to that component.

Comment 7 Sergio Basto 2012-05-29 22:55:13 UTC
please see if it is not a prelink problem as describe in 
https://bugzilla.redhat.com/show_bug.cgi?id=825602#c4

Comment 8 David Zeuthen 2012-05-31 12:16:34 UTC
Reassigning to polkit-kde, I think that's the component for KDE's polkit authentication agent. Otherwise please reassign to the proper component - thanks!

Comment 9 David Zeuthen 2012-05-31 12:17:08 UTC
*** Bug 826459 has been marked as a duplicate of this bug. ***

Comment 10 Kevin Kofler 2012-05-31 13:03:58 UTC
Does:
su -c "authconfig --updateall"
fix the problem?

Comment 11 Rex Dieter 2012-05-31 15:31:44 UTC
If problems persist after implementing comment #10, please give output of:

$ loginctl list-sessions

if it lists your login session, post output from

$ loginctl show-session <X>

where <X> is your session number.

Comment 12 Kevin Kofler 2012-05-31 16:02:08 UTC
*** Bug 827093 has been marked as a duplicate of this bug. ***

Comment 13 Robert Gadsdon 2012-05-31 16:22:24 UTC
# authconfig --updateall (as root) makes no difference..   (startx) KDE USB disk mount still fails, with ..'Not Authorized'..

# loginctl list-sessions
   SESSION        UID USER             SEAT            
         1       1000 rgadsdon         seat0 

# loginctl show-session 1 (from KDE konsole xterm)
Id=1
Timestamp=Thu, 31 May 2012 18:03:27 +0100
TimestampMonotonic=15201092
DefaultControlGroup=name=systemd:/user/rgadsdon/1
VTNr=1
TTY=tty1
Remote=no
Service=login
Leader=463
Audit=1
Type=tty
Class=user
Active=no
KillProcesses=no
IdleHint=yes
IdleSinceHint=300000000
IdleSinceHintMonotonic=0
Name=rgadsdon

BUT:

# loginctl show-session 1 (from console session only - X/KDE not running)
Id=1
Timestamp=Thu, 31 May 2012 18:03:27 +0100
TimestampMonotonic=15201092
DefaultControlGroup=name=systemd:/user/rgadsdon/1
VTNr=1
TTY=tty1
Remote=no
Service=login
Leader=463
Audit=1
Type=tty
Class=user
Active=yes
KillProcesses=no
IdleHint=no
IdleSinceHint=300000000
IdleSinceHintMonotonic=0
Name=rgadsdon

and # udisks --mount ....  works correctly..

..

Robert Gadsdon.

Comment 14 Kevin Kofler 2012-05-31 16:26:30 UTC
The Active=no is the problem. I guess systemd does not support startx.

Does everyone seeing this issue use startx?

Comment 15 Andrew 2012-05-31 16:31:28 UTC
(In reply to comment #14)
> Does everyone seeing this issue use startx?
As for me, it's true.

Comment 16 Kevin Kofler 2012-05-31 16:39:32 UTC
So the problem in this case seems to be that systemd-logind gets confused by startx, so a bug in either systemd or startx. What I don't know is whether startx is involved in bug #827093 or whether it's actually separate.

Comment 17 Kyle Pablo 2012-05-31 16:44:00 UTC
$ loginctl list-sessions
   SESSION        UID USER             SEAT            
         1        500 binaryhat        seat0           

1 sessions listed.


$ loginctl show-session 1
Id=1
Timestamp=Thu, 31 May 2012 10:52:26 -0400
TimestampMonotonic=42246124
DefaultControlGroup=name=systemd:/user/binaryhat/1
VTNr=1
TTY=tty1
Remote=no
Service=login
Leader=873
Audit=1
Type=tty
Class=user
Active=no
KillProcesses=no
IdleHint=yes
IdleSinceHint=300000000
IdleSinceHintMonotonic=0
Name=binaryhat

Comment 18 Kevin Kofler 2012-05-31 16:45:51 UTC
So you have Active=no too. How are you starting KDE?

Comment 19 Robert Gadsdon 2012-05-31 17:01:24 UTC
This problem was summarised in Bug 826459 (closed..)

Login via 'graphical' boot (runlevel 5) - everything works correctly.
Login via 'multi-user' boot (runlevel 3) - start KDE session using # startx - USB disk mount fails with 'Not Authorized'..

Robert Gadsdon.

Comment 20 Kyle Pablo 2012-05-31 17:10:04 UTC
(In reply to comment #18)
> So you have Active=no too. How are you starting KDE?

startx from runlevel 3.

Comment 21 Lennart Poettering 2012-05-31 17:15:01 UTC
startx is not really supported in F17. If we want to resurrect it we need it to stay on the VT it is started from instead of allocating a new one. THis should actually be realatively simple todo (and i thinkt there's a bug about that somehwere).

We can't support "forking off" sessions from other sessions, due to the audit session ID being sealed off. Hence temporarily "upgrading" the tty session to a graphical one is the only sane (and relatively simple) way to go if we care about startx for longer.

Comment 22 David Zeuthen 2012-05-31 17:15:28 UTC
(In reply to comment #16)
> So the problem in this case seems to be that systemd-logind gets confused by
> startx, so a bug in either systemd or startx. What I don't know is whether
> startx is involved in bug #827093 or whether it's actually separate.

Yeah, looks like it's either systemd-login / startx(1) problem and not KDE as I originally thought, sorry. Talking to Lennart he says startx(1) or X needs to somehow "upgrade" the existing session instead of switching to a separate VT. I've included some relevant IRC chat in [1].

I would reassign it this to startx(1) (in the xorg-x11-xinit package).


[1] :

<davidz> mezcalero: mmm, systemd-logind and startx, they don't work well together on f17 do they?
<davidz> mezcalero: https://bugzilla.redhat.com/show_bug.cgi?id=820675
<drago01> startx is heading towards the way of the dodo
<davidz> I know, but people file bugs :-)
<mclasen> given that it is a stupid shell script written by some mit undergrad in the 80s, it had a pretty good run...

<mezcalero> davidz: no, they don't work well together
<mezcalero> davidz: there was talk about making startx "upgrade" an existing tty session to a graphical session
<halfline> davidz: there's already a bug about that
<mezcalero> davidz: but nobody did anything on that
<davidz> mezcalero: I guess we can blame startx(1) - I mean, if startx(1) wanted, it could poke systemd-loginctl, right?
<mezcalero> davidz: due to the sealing off of the audit session stuff we can't allow "forking off" sessions from other sessions
<mezcalero> which means we need to to this upgrading of sessions if we want to support startx style thing
<davidz> I see
<mezcalero> davidz: no, startx can't poke logind
<mezcalero> davidz: the fix is actually pretty easy
<mezcalero> we'd need to tell X not to switch to a different VT
<mezcalero> but to stay on the VT it was started from
<mezcalero> it's a complex problem with a surprisingly simple solution
<mezcalero> but nobody bothered to fix this in startx so far

Comment 23 Kevin Kofler 2012-05-31 17:22:46 UTC
So in short, everyone experiencing this, use a graphical login manager (such as KDM) instead of startx and your desktop will work fine.

Comment 24 Andrew 2012-05-31 17:37:15 UTC
(In reply to comment #23)
> So in short, everyone experiencing this, use a graphical login manager (such
> as KDM) instead of startx and your desktop will work fine.
You mean using graphical.target instead of multi-user.target or just starting X with KDM, not startx?

Is there any [modern] way to launch X session when started with multi-user.target?

Comment 25 Robert Gadsdon 2012-05-31 17:44:31 UTC
For my particular workflow, having to login using runlevel 5 / KDM is a pain, so I'm just running with a hacked version of /usr/share/polkit-1/actions/org.freedesktop.udisks.policy, until a fix is available..

Robert Gadsdon.

Comment 26 Andrew 2012-06-02 10:27:54 UTC
(In reply to comment #24)
> starting X with KDM, not startx

I'm partially answering to myself: kdm can't be used as a straight startx alternative because of at least root privileges requirement. Starting it with sudo leads to authentication request despite already existing user session.

Maybe it can be changed with GreeterUID in kdmrc, but I don't know the side effects of that.

Comment 27 Kevin Kofler 2012-06-02 17:08:10 UTC
*** Bug 827727 has been marked as a duplicate of this bug. ***

Comment 28 Sergio Basto 2012-06-03 17:20:59 UTC
(In reply to comment #11)
> If problems persist after implementing comment #10, please give output of:
> 
> $ loginctl list-sessions
> 
> if it lists your login session, post output from
> 
> $ loginctl show-session <X>
> 
> where <X> is your session number.

this commands could be useful in other cases , but now the command seems to be systemd-loginctl 

$ /bin/systemd-loginctl list-sessions
   SESSION        UID USER             SEAT            
         1        500 sergio           seat0           

1 sessions listed.

$ /bin/systemd-loginctl show-session 1
Id=1
Timestamp=Sun, 03 Jun 2012 04:40:39 +0100
TimestampMonotonic=64039167
DefaultControlGroup=name=systemd:/user/sergio/1
VTNr=1
Display=:0
Remote=no
Service=kdm
Leader=1282
Audit=1
Type=x11
Class=user
Active=yes
KillProcesses=no
IdleHint=no
IdleSinceHint=0
IdleSinceHintMonotonic=0
Name=sergio

in my case is working , but I don't use startx, I run in graphical mode with 
$ cat /etc/sysconfig/desktop 
DESKTOP="KDE"
DISPLAYMANAGER="KDE"

Comment 29 Sergio Basto 2012-06-03 21:46:49 UTC
(In reply to comment #28)
> 
> this commands could be useful in other cases , but now the command seems to
> be systemd-loginctl 

sorry I'm wrong here, loginctl exists on F17. Just doesn't exist on F16 with systemd-37-19.fc16.i686

if you have at /etc/sysconfig/prelink 
PRELINK_OPTS=-mR

Please try:
$ prelink -mR -va (as root) 
and reboot computer. 

to find out if is a prelink issue .

Comment 30 Kevin Kofler 2012-06-03 22:03:39 UTC
This issue has absolutely nothing to do with prelink, except maybe in your case, which you reported separately. What is actually happening has already been explained in comment #21 and comment #22. In addition, the workaround which you say solved the issue for you has been confirmed in (duplicate) bug #827093 NOT to fix this startx issue. Your issue seems to be completely different. Please do not spread confusion and misinformation in this bug report.

Comment 31 Russ 2012-06-04 11:39:28 UTC
(In reply to comment #14)
> The Active=no is the problem. I guess systemd does not support startx.
> 
> Does everyone seeing this issue use startx?

It seems so. It is at least for me.

I was trying to figure out how I got onto this bug while reading my email. Seems my bug https://bugzilla.redhat.com/show_bug.cgi?id=827727 is a duplicate. I was also about to search for a bug about the USB issue in the first post, as that problem is also quite annoying.

I thought they both could be related to a permissions issue. But I would have never thought it would be related to systemd :o

>startx is not really supported in F17.

It needs to get supported quickly. A lot of people still use startx. A lot of servers use RHEL. Servers certainly should not need level 5. But they still will likely need to get to a GUI for maintenance at some point in their life. A lot of people like me hate using a DM, as too much work is done on the console.

This is a major issue for me on my test system. I'm with Robert in #25 concerning KDM. Using KDM is out of the question for our situation. This issue will could be a deal breaker preventing us from upgrading to F17 on any production systems until it is resolved. I don't know what other things in KDE it may affect besides logout and mounting disks.

Comment 32 Russ 2012-06-04 12:54:51 UTC
just found a new problem which most likely is related to this bug:

from konsole after startx: ping: icmp open socket: Operation not permitted

You need to be root now just to do a ping . . .

Yikes!!

Comment 33 Andrew 2012-06-04 13:03:27 UTC
(In reply to comment #32)

> from konsole after startx: ping: icmp open socket: Operation not permitted

Check iptables / SELinux maybe. I have subject issue, but ping is ok for me. Launched from Konsole after startx:

$ ping -c 2 google.com
PING google.com (209.85.148.139) 56(84) bytes of data.
64 bytes from fra07s07-in-f139.1e100.net (209.85.148.139): icmp_req=1 ttl=55 time=59.8 ms
64 bytes from fra07s07-in-f139.1e100.net (209.85.148.139): icmp_req=2 ttl=55 time=51.1 ms

--- google.com ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 51.121/55.470/59.819/4.349 ms

Comment 34 Kevin Kofler 2012-06-04 13:35:44 UTC
Indeed, ping does not use the systemd-logind session information, so the ping issue is separate.

Comment 35 Russ 2012-06-05 10:15:41 UTC
(In reply to comment #34)
> Indeed, ping does not use the systemd-logind session information, so the
> ping issue is separate.

Thanks for that info Kevin.
 
/bin/pin and /bin/ping6 are missing capability cap_net_raw after yum upgrade from F16 on my test system:

rpm -q --filecaps iputils
/etc/sysconfig/rdisc
/usr/bin/ping   = cap_net_raw+ep
/usr/bin/ping6  = cap_net_raw+ep

getcap -v /bin/ping
/bin/ping

So capability cap_net_raw has ended up missing somehow. . .

Running setcap cap_net_raw=ep /bin/ping fixes the problem:
$ ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_req=1 ttl=64 time=0.489 ms

I would bet this has something to do with usrmove. I wonder what else got messed up during the upgrade.

Comment 36 Michal Schmidt 2012-06-12 13:18:50 UTC

*** This bug has been marked as a duplicate of bug 806491 ***


Note You need to log in before you can comment on or make changes to this bug.