Using startx on Fedora 17, a non-root user cannot join new wireless networks -- how to fix?

Question

I have Fedora 17 installed on a Lenovo X230, and if I leave it configured to boot into Gnome using systemd's runlevel5.target (or graphical.target), which is the default, networking seems to work just fine -- a local user can join a new wireless network, authenticating and saving a network password as needed. So far, so good.

However, this laptop's owner prefers to boot into a non-graphical display (systemd's runlevel3.target or multi-user.target); when desired, he runs startx to get Gnome started. When Gnome is started this way, the user cannot join any new wireless network; you can select the desired SSID from the drop-down list, but no prompt for network password appears, and no connection is made. I don't see anything relevant logged in /var/log/messages.

What can be done, so that a non-privileged user who has started Gnome using startx can be allowed to join new wireless networks?

Notes:

If root logs in, starts Gnome, and joins the new wireless network, then appropriate new files are created under /etc/sysconfig/network-scripts for the network and key information. Once this is done, the non-root user can use the wireless network when he logs in. This workaround is horribly inconvenient.

The user is already a member of group 'wheel' and has full sudo access without password. SELinux is disabled on this machine.

As a test, I added the user to group 'root', and made /etc/sysconfig/network-scripts group-writable. This didn't help or change anything.

Answer 1

My guess is that, when you run startx, you don't have an active ConsoleKit session. See e.g. Set up PolicyKit permissions in the Arch Linux wiki entry for NetworkManager. It shows you how to use ck-launch-session in your ~/.xinitrc to make sure you have a proper CK session.

You also need to make sure that PolicyKit permissions are right, although they're probably already fine if things work from inside a Gnome session.

If the command ck-list-sessions shows a difference between using runlevel5.target versus runlevel3.target+startx, then this is probably your issue.

See also:

Administration and Privilege at the bottom of the Network Manager Configuration page.

---

I don't recommend that you follow what these say without understanding what they're doing, since it's not necessarily clear how they relate to Fedora, but they might be useful reading:

This Ubuntu bug: If 'startx' is run from within a text console, ConsoleKit session is not marked 'active'

This Debian mailing list post that has some details about changing policykit/consolekit permissions: Re: What is the right way to use consolekit with startx?

Answer 2

Short answer -- use:

 startx -- vt0

Longer explanation: The links and suggestions by @JimParis led me to dig a bit more into PolicyKit and systemd, and -- crucially -- to google for "polkit startx", which led me to a result on an Arch Linux discussion site:

If you don't use a display manager, it means you won't have a registered pam session for your graphical login, which means logind won't give the correct info to polkit (it will think that there is no active session).

A workaround for this is to start your WM on the same VT as your consolelogin, and hence "steal" that pam session. I believe the magic incantation is:

# startx -- vt0

Until now, I hadn't even noticed that startx can take arguments, but this works beautifully for my situation. Not only can the local user now join wireless networks properly, but has proper access to other Gnome desktop features such as bluetooth and Suspend.