PDA

View Full Version : [SOLVED] xinitrc and Permissions in Fedora 17



326bd935
12th August 2012, 03:01 AM
Before F17 I could simply start an X session with the following in ~/.xinitrc:

ck-launch-session dbus-launch openbox-session

Now that the password reset feature finally works on this forum I can finally ask this question.

How do I startx and get permissions the same way as in F16 with the .xinitrc above in F17?

I know there is no consolekit in F17 but I can't get permissions with the following in .xinitrc:

dbus-launch fvwm
or:

fvwm

I have had to add myself to a number of groups to get functionality but I don't see it as reasonable to have to add myself to the disk group just to mount hard drives.
I have seen a KDE instalation work fine without consolekit so how do I start an X session with .xinitrc properly?

smr54
12th August 2012, 03:35 AM
Hrrm, openbox has worked fine for me with exec openbox-session in F17. Not sure what functionality you're missing. (I never put in any dbus stuff).
I also add myself to video and audio to be able to work with sound and with a webcam.

I've not had to do anything special regarding console kit for awhile and I always log in text mode and get into X with startx.

Your example mentions fvwm--was it any different in openbox? (I've never put any dbus stuff in my xinitrc, nor have I had to be a member of the disk group.

326bd935
12th August 2012, 04:04 AM
Hrrm, openbox has worked fine for me with exec openbox-session in F17. Not sure what functionality you're missing. (I never put in any dbus stuff).
I also add myself to video and audio to be able to work with sound and with a webcam.

I've not had to do anything special regarding console kit for awhile and I always log in text mode and get into X with startx.

Your example mentions fvwm--was it any different in openbox? (I've never put any dbus stuff in my xinitrc, nor have I had to be a member of the disk group.

The main thing I think is that I have to type root password for mounting USB flash drives in pcmanfm. Also commands such as

dbus-send --system --print-reply --dest="org.freedesktop.UPower" /org/freedesktop/UPower org.freedesktop.UPower.Suspend
say permission denied. Also I believe you don't need to be in the group 'audio' for audio or 'video' for capture devices as the standard Fedora installation doesn't add you to these groups and everything works fine.
I started openbox the same way as fvwm and I just tried only 'openbox' in xinitrc and still no luck.

If it helps then systemd-loginctl outputs only 1 session which I guess is the console login whereas ck-list-sessions would list my graphical sessions too. - EDIT: a standard fedora install also only lists 1 session.
I have looked for systemd-loginctl related documentation but it seems there isn't really any.

smr54
12th August 2012, 04:17 AM
Ah, Ok, I wouldn't know about that one then. (When I do mount a USB, I do it with sudo, and don't do it often enough to look into getting permissions to do it as regular user) Sorry I can't be of more help.

326bd935
12th August 2012, 03:01 PM
Found something:
https://bugzilla.redhat.com/show_bug.cgi?id=820675#c21

So... it seems Fedora's great lets use systemd-loginctl isn't actually 100% complete. It seems startx cannot work with it. It also seems there is a (sort of) workaround and that is to start X sessions in the same vt as the console session.

Basically if you are on tty1 and want to start X you do the following:

startx -- :0 vt1


Now I just need to modify my startx executing script and i'll try to post something up by tomorrow.

secipolla
12th August 2012, 04:12 PM
I don't think you need anything dbus related, at least not for openbox session.

Anyway, one way to check at login (that I got from somewhere as I don't understand these things) is with


if which dbus-launch >/dev/null && test -z "$DBUS_SESSION_BUS_ADDRESS"; then
eval "$(dbus-launch --sh-syntax --exit-with-session)"
fi

Also regarding consolekit, it's dropped from GNOME, not from Fedora. Even Xfce still uses it.
You can install it.

smr54
12th August 2012, 04:51 PM
Odd. That bug sounds as if startx doesn't work, whereas it does for me. That is, looking at the bug, it's as if they plan to drop startx, and that this has happened in F17, but that doesn't seem to be the case for me. I can startx from any tty, I don't have to be on tty1.

secipolla
12th August 2012, 07:43 PM
BTW, consolekit is used by Xfce only for its logout dialogue.

To mount drives in pcmanfm you only need gvfs, AFAIK.

polkit-gnome is useful too for apps that require it for authentication like yumex.
You start it with:
/usr/libexec/polkit-gnome-authentication-agent-1

I have Icewm (login with lightdm) and pcmanfm auto-mount drives just fine.

326bd935
13th August 2012, 05:58 AM
BTW, consolekit is used by Xfce only for its logout dialogue.

To mount drives in pcmanfm you only need gvfs, AFAIK.

polkit-gnome is useful too for apps that require it for authentication like yumex.
You start it with:
/usr/libexec/polkit-gnome-authentication-agent-1

I have Icewm (login with lightdm) and pcmanfm auto-mount drives just fine.

Yea I see now, that must be why even for the lxde logout dialogue too you still need consolekit.
I tried today and I need dbus-launch in .xinitrc for pcmanfm to show drives in my fvwm session (even though i have almost every gvfs-* except smb).

I now just start X with the following script in ~/.x simply by executing ./.x
the only thing missing would be to find the lowest screen number not used so you don't even have to specify that if starting multiple sessions but my sh skills are pretty basic.


#!/bin/sh

if [ -z $1 ]
then screen=0
elif [ $1 -ge 0 ]
then screen=$1
else
echo "Expected screen number, got: $1"
exit
fi

if [ -e /tmp/.X${screen}-lock ]; then
echo "Fatal server error:"
echo "Server is already active for display $screen"
echo " If this server is no longer running, remove /tmp/.X${screen}-lock"
echo " and start again."
echo "You can set screen number as the first Parameter."
exit
fi

vt=$(tty | cut -d 'y' -f 2)

echo Starting X Session: screen $screen, tty$vt
startx -- :$screen vt$vt &> ~/.Xstdo$screen

rm ~/.Xstdo$screen
echo X Session Closed

The reason I forward output is because then I can view it in a conky window on my desktop along with /var/log/messages.

I find this quite interesting because it also seems to be better for security to start X in the same vt as the console session as usually you can switch to the console, kill X and you have full user access even if the X screen was locked.