Only unprivileged desktop session

Forum / NoMachine for Linux / Only unprivileged desktop session

Tagged: ,

Viewing 6 posts - 1 through 6 (of 6 total)
  • Author
    Posts
  • #17904
    socoho
    Participant

    Hello,

    I’m new to NM/NX and probably don’t understand all the settings and features yet so I’m not sure if this is even possible.

    1) I would like to use my server remotely the same way as I do locally. But if I log-in (using NX-private-key) and let NM create a new display/desktop session everything works fine except that my sudo/wheel privileges aren’t active:

    I don’t have access to power management so I can’t reboot or power off the server anymore.
    GUI authentication prompts (for sudo actions) don’t pop up anymore.
    “XDG_RUNTIME_DIR not set” warnings appear on different shell commands.

    I guess the issue is that the session is not initialized by systemd since loginctl doesn’t list any sessions when I connect with NM.

    Do I have to modify my DefaultDesktopCommand or some other settings to make this work?

    2) If CreateDisplay 1 is set for the user then NX creates a session even before the user connects. Is this working as intended?

    Details:

    NoMachine for Linux 6.0.78 on host (Arch)
    NoMachine Enterprise Client 6.0.80 on client (Windows 1709)
    I guess it’s a virtual display since I couldn’t change resolution when connected to physical display earlier
    KDE Plasma (tested with and without SDDM)

    #17945
    Cato
    Participant

    Hello socoho,

    Properly configured NoMachine server should be able to provide you with the same user’s experience you’ve got when using your desktop locally. In fact, physical display session allows users to operate directly on current physical desktop of machine. If this session is not present in the sessions list, you most likely need to add connecting user to group of NoMachine’s administrators.
    To do so, run the following command from terminal, using root account:

    ./nxserver –useradd <user_name> –administrator

    Even if above instruction help you to use NoMachine in the way you desired, the behavior of virtual session you previously described is still incorrect. I suspect that the problem might be related to NX PAM configuration. Does the issue occur when you use NoMachine with SSH protocol? If not, you can try to reuse SSH PAM configuration with NX:

    1. Start the terminal on server machine and su to root.

    2. Create the backup of NX pam configuration:

    cp /etc/pam.d/nx /etc/pam.d/nx.bak

    3. Overwrite current configuration with sshd settings:

    cp /etc/pam.d/sshd /etc/pam.d/nx

    4. Check if problem is stil present.

    5. If so, please check what happens when you use password authentication method instead of keys.

    If problem persists despite modifying PAM, gather server-side logs according to instructions from:

    https://www.nomachine.com/DT07M00098#1

    Send them to forum[at]nomachine[dot]com.

    #17955
    socoho
    Participant

    Hello Cato,

    thank you for the support! Changing nx PAM from

    auth       include       su
    account    include       su
    password   include       su
    session    include       su

    to (sshd configuration)

    auth      include   system-remote-login
    account   include   system-remote-login
    password  include   system-remote-login
    session   include   system-remote-login

    solved almost all unprivileged issues except the power management from KDE.
    But I can just use “sudo systemctl reboot/poweroff/hibernate/…” for that.
    And loginctl lists now two sessions:

    socoho (1000)
    Since: Tue 2018-03-20 16:05:28 CET; 13min ago
    State: active
    Sessions: c3 *c2
    Linger: no
    Unit: user-1000.slice
    ├─session-c2.scope
    │ ├─ 489 /usr/NX/bin/nxexec --node --user socoho --priority realtime --mode 0 --pid 13
    │ ├─ 500 /usr/NX/bin/nxnode.bin
    │ ├─ 550 /bin/sh /usr/sbin/startkde
    │ ├─ 570 /usr/bin/dbus-launch --exit-with-session startkde
    │ ├─ 574 /usr/bin/dbus-daemon --syslog --fork --print-pid 5 --print-address 7 --session
    │ ├─ 580 /usr/bin/pulseaudio --high-priority=no
    │ ├─ 581 /usr/NX/bin/nxclient.bin --monitor --pid 550
    │ ├─ 586 /usr/lib/pulse/gconf-helper
    │ ├─ 773 /usr/lib/kf5/start_kdeinit --kded +kcminit_startup
    │ ├─ 774 kdeinit5: Running...
    │ ├─ 775 /usr/lib/kf5/klauncher --fd=9
    │ ├─ 778 kded5 [kdeinit5]
    │ ├─ 785 /usr/sbin/kaccess
    │ ├─ 792 kwrapper5 /usr/bin/ksmserver
    │ ├─ 795 /usr/bin/ksmserver
    │ ├─ 799 /usr/bin/kglobalaccel5
    │ ├─ 804 /usr/lib/dconf/dconf-service
    │ ├─ 822 /usr/sbin/kwin_x11
    │ ├─ 824 /usr/sbin/krunner
    │ ├─ 826 /usr/sbin/plasmashell
    │ ├─ 832 /usr/lib/polkit-kde-authentication-agent-1
    │ ├─ 834 /usr/sbin/xembedsniproxy
    │ ├─ 859 /usr/lib/kf5/kscreen_backend_launcher
    │ ├─ 879 /usr/bin/kactivitymanagerd start-daemon
    │ ├─ 958 /usr/sbin/ksysguardd
    │ ├─ 975 /usr/bin/kuiserver5
    │ ├─1243 /usr/sbin/konsole
    │ ├─1251 /bin/bash
    │ ├─1285 /usr/sbin/dolphin
    │ ├─1442 loginctl user-status socoho
    │ └─1443 less
    ├─session-c3.scope
    │ ├─957 /usr/NX/bin/nxexec --node --user socoho --priority realtime --mode 0 --pid 13 -H 5
    │ └─963 /usr/NX/bin/nxnode.bin -H 5
    └─user@1000.service
    ├─dbus.service
    │ ├─683 /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
    │ └─685 /usr/lib/GConf/gconfd-2
    ├─init.scope
    │ ├─490 /usr/lib/systemd/systemd --user
    │ └─491 (sd-pam)
    └─pulseaudio.service
    ├─680 /usr/bin/pulseaudio --daemonize=no
    └─682 /usr/lib/pulse/gconf-helper
    
    Mar 20 16:19:04 vm ksmserver[795]: CreateNotify: 60817451
    Mar 20 16:19:06 vm kcheckpass[1425]: pam_tally(kde:auth): Error opening /var/log/faillog for update
    Mar 20 16:19:06 vm kcheckpass[1425]: pam_tally(kde:auth): Error opening /var/log/faillog for read
    Mar 20 16:19:06 vm kcheckpass[1425]: pam_tally(kde:setcred): Error opening /var/log/faillog for update
    Mar 20 16:19:06 vm kcheckpass[1425]: pam_tally(kde:setcred): Error opening /var/log/faillog for update
    Mar 20 16:19:06 vm ksmserver[795]: UnmapNotify: 60817441
    Mar 20 16:19:06 vm ksmserver[795]: UnmapNotify: 60817441
    Mar 20 16:19:06 vm ksmserver[795]: CreateNotify: 60817460
    Mar 20 16:19:06 vm kwin_x11[822]: QXcbConnection: XCB error: 3 (BadWindow), sequence: 59713, resource id: 60817460, major code: 18 (ChangeProperty), minor code: 0
    Mar 20 16:19:06 vm ksmserver[795]: Grab Released

    Is the second session (c3) needed or is something wrong?

    • This reply was modified 6 years, 7 months ago by Britgirl.
    • This reply was modified 6 years, 7 months ago by socoho.
    #17957
    socoho
    Participant

    Regarding issue 2) there seems to be a bug when “Always create a new display on this server” is checked on connection.
    The value for DisplayOwner isn’t set correctly in server.cfg if the line is already active:
    Before:

    DisplayOwner ""
    After:
    

    DisplayOwner “”

    I’ve reset CreateDisplay to 0 again since I don’t want NX to create my user session automatically when the machine starts before I connect/login. Do you know why this is happening and if there is a setting for that?

    #17975
    Cato
    Participant

    Hello socoho,

    It appears that modifying NX PAM configuration results in creation of one systemd session for each NoMachine PAM session. I don’t see anything wrong with that. In case you wonder, there’s one session responsible for starting, monitoring and enabling remote access to your virtual desktop and one session managing current connection to this desktop.

    As for DisplayOwner, the value of this setting can only be set manually. You place there the name of account which will own the virtual desktop created during startup of nxserver. This will only take place if you enable and set:

    CreateDisplay 1

    In other words, the behavior you described is correct.

    #17973
    socoho
    Participant

    Sorry, formatting is weird and text was truncated.
    It should be: DisplayOwner “”
    was set to nameDisplayOwner “”.

Viewing 6 posts - 1 through 6 (of 6 total)

This topic was marked as solved, you can't post.