When machine is headless, user is no longer privileged

Question

The core issue is: ANY gnome session not sitting ontop of a real physical/native display --or shadowing that display (ie. NXserver's shadow mode)-- has faulty privileges. Even when run as root!

Any comments on a way to fix the problematic behavior for the VNC/non-shadow NX sessions?

---

I'm upgrading my home Ubuntu headless server after a long while, and I'm having lots of problems that I do not remember existing in previous Ubuntu versions.

Some details:

• I started with ubuntu-11.04-server-amd64.iso and then installed ubuntu-desktop on-top of it.
• uname -a: Linux MiddleEarth 2.6.38-8-server #42-Ubuntu SMP Mon Apr 11 03:49:04 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
  
• The hardware is Intel D920, 2GB Ram, gfx is some fan-less nvidia 6600, 3xGigabit, 1x100mbit, no monitor,keyboard,mouse attached.

---

Round 1

While I was doing the testing/setting up with a monitor attached, everything was peachy, both when sitting infront of that monitor and when VNCing in from my desktop machine (into vino).

Without a monitor though problems arise:

[Unsolved/Dropped]

The very first problem was vino being stubborn and not liking to load before/during GDM. But since this is a headless system, I dont really need it to start with X by default (ie change the init level) anyways, so that's a bit moot. However, I distinctly remember this being very easy to do in an older ubuntu version ( v9.04 I think ). And it worked fine; but not any more!? ... anyways I dropped that idea altogether.

[Solved]

Then it was Unity/effects messing VNC (Solved it by cheating).

[Unsolved]

I originally switched to NXserver hoping that maybe the following problems are tightvnc or vino issues, but no such luck. (Note: read round2)

When remoting in via VNC (or NXserver) my user account loses the ability to mount/unmount HDDs.

When remoting in via VNC (or NXserver) my user account cannot access some priviledged configuration options,
some examples:

• cannot do anything (ie. 'add' a user or 'advanced settings') in "System -> Administration -> Users and Groups".
• cannot use 'unlock' in "System -> Administration -> Login Screen".
• gparted fails to get any information about the filesystems.
• etc. (various other admin/config dialogues don't properly work either)

I can only guess this has something to do with user privileges not being assigned properly when an actual physical monitor device is not connected.
The reason 'WHY' this happens in ubuntu 11.04, when it is headless, escapes me; I do not remember this behaviour in previous versions of ubuntu.

Do note that the HDD mounting problem is a non-issue for internal/static hdds (I just add them to fstab since they're static anyways). But really a big pain for removable usb media.

The rest of the problems, I have not figured out how to fix...
I know what you're thinking... log in to ssh, sudo su, and run vncserver under root entirely?

Surprise Surprise! root's gui is broken too: gparted fails to get info, user&groups is entirely grayed out (this is a different behaviour than my regular user). Weirdly enough the Login screen administration proggy seems to work fine.

---

Round 2

( NOTE: I do not know if this did or did not make a difference to the outcome. At some point between round 1 and round 2, I applied the changes mentioned in posts #21 and #24 in this thread )

The regular tightvnc/NXServer sessions have the same behaviour, BUT...

[Partial Solution/The actual problem is still there]

In the NXClient connection settings, when I choose the 'shadow' mode (shadow attaches you to the native display, ie. desktop shadowing)...

Everything works perfect inside this session!

One thing I noticed is that it immediately asks me for a keyring password... maybe the whole mess has something to do with the keyring system gnome uses?

But, if I connect with a regular (not shadow) NX connection, or a regular vnc it goes back to having the same problems.

P.S. There were a couple of days inbettween when I wrote round1 and round2 (I was keeping it in a txt file locally). I was testing out various sugestions to see what would work, which is why I don't know for sure if that xorg.conf VNC device edit or that nomodeset setting made a difference.

[EDIT 2011-06-10]

NXServer and GDM

At the time of writing I had set the system up to auto-login, which was why the shadow connection just simply worked. When I later disabled that and rebooted the system, NX gave an error, but with a little bit of Googling I found this thread

These are the uncommenting & changes I did on my /usr/NX/etc/server.cfg:

EnableAdministratorLogin = "1"
EnableSessionShadowing = "1"
EnableInteractiveSessionShadowing = "1"
EnableSessionShadowingAuthorization = "0"
EnableDesktopSharing = "1"
EnableInteractiveDesktopSharing = "1"
EnableFullDesktopSharing = "1"
EnableAdministratorDesktopSharing = "1"
EnableDesktopSharingAuthorization = "0"
EnableSystemDesktopSharingAuthorization = "0"

(If it was a more public network, ie university/large office I'd probably use a little stricter settings, but these suit me fine.)

After a reboot I logged in with nxclient to the desktop 'shadow' (native display) setting and got GDM! :D

Unfortunately clipboard doesn't work in the 'shadow' session (It works on the other/regular ones fine)

[EDIT 2011-06-11]
Stumbled upon Xvfb but it has the same issues when used like this:

Xvfb :2 -ac -screen 0 1280x1024x32 -pixdepths 8 24  2>&1 >/dev/null &
export DISPLAY=:2
gnome-session --session=2d-gnome 2>&1 >/dev/null &
x11vnc --display :2 --passwd blahblah

Answer 1

I located the culprit.
Tested on a fresh install, confirmed it's a bug.

I submitted a bug report

In short the issue is: The polkit authentication dialogue will show up on DISPLAY :0 instead of DISPLAY :1 where the VNC/NX session is.

A workaround may be to use libpam-keyring to auto authenticate upon login.
or... scratch that, that probably would not do it, a change for all policy kit settings from 'auth_admin' to just 'yes' would probably fix the issue, and that of course would make policyKit moot altogether... sigh

Answer 2

I think this is the correct PolicyKit behavior.

The policy for Active, Inactive and Any other user are different, so when you are connected through NX you are not Active (clients in active sessions on local consoles), nor Inactive (clients in inactive sessions on local consoles), but you result as Any user.

You can see the default policy for the Action under policy control for the different type of users with the command

pkaction --verbose

As you can see, the user of type Any is limited with comparison to Active users.

To remedy, you can modify the default policy. In the following a suggest an awk script to create a policy kit file to put in the right location. This is the script:

#!/usr/bin/awk -f

/^[^ ]/ {
  action = substr($0, 1, length($0) - 1)
}
/^ / {
  if ($1 == "description:") {
    $1 = ""
    description = substr($0, 2)
    if (description == "")
      description = action
  } else if ($1 == "implicit") {
    if ($2 == "any:")
      any = $3
    else if ($2 == "inactive:")
      inactive = $3
    else if ($2 == "active:") {
      active = $3
      print ""
      print "[" description "]"
      print "Identity=unix-group:admin"
      print "Action=" action
      print "ResultActive="   active
      print "ResultInactive=" active
      print "ResultAny="      active
    }
  }
}

Suppose you call it create-policy. Make it executable, the execute the script with

pkaction --verbose | ./create-policy > local.pkla 

then move the resulting file:

sudo mv local.pkla /var/lib/polkit-1/localauthority/50-local.d/

You now should have the same right as you were a local session user.

Answer 3

I was running into a similar issue with NX and found the following thread:

Why do I get Unity instead of Classic when using NX?

I edited my Windows NX client so the desktop is set to Unix & Custom, then set it to run the following command:

gnome-session --session=classic-gnome

And selected New Virtual Desktop.
After that I was good to go.