Always create a new display on this server – allows any user to lock down system

Forums / NoMachine for Linux / Always create a new display on this server – allows any user to lock down system

Viewing 5 posts - 1 through 5 (of 5 total)
  • Author
    Posts
  • #29409
    Avatardefactoman
    Participant

    Environment: NoMachine Enterprise Desktop Evaluation – Version 6.11.2

    OS: CentOS 7.8

    NoMachine Version:  Linux Desktop

    Operating environment: One desktop – Linux Desktop – Multiple users will use it over the day.   It operates without anyone at the console – 1 person at a time.     OS is running with systemctl set-default multi-user.target so boots to the console.   One monitor is connected to the system.

    Problem: When a user connects for first time they will get a message “Cannot detect any display running. Do you want NoMachine to create a new display and proceed to connect to the desktop?”  and are presented with a check box labeled “Always create a new display on this server”.  ANY user (privileged or non-privileged) checking this box will lock down all further connection attempts to it’s desktop.   If no one checks the box, everything works normally.

    Details:

    • When ANY user (privileged or non-privileged) checks the box “Always create a new display on this server” the server.cfg in /usr/NX/etc/server.cfg is modified in the following way:
      • CreateDisplay 0 is commented out
      • CreateDisplay 1 is added in
      • DisplayOwner “” is commented out
      • DisplayOwner is added in with the name of the user who “checked the box
    • Once “DisplayOwner <username>” is set, no other users can connect as all new sessions are spawned under that specific user.

    Question:

    How do you stop someone from checking that box and stopping everyone else?

     

    Thoughts:

    Seems weird an unprivileged user gets to modify the server.cfg for the whole system.  I suppose I could forcefully lock down the sever.cfg with a chmod, but im wondering if maybe im missing something.  If no one checks the box, everything works normally.  As soon as someone checks the box, it ruins it for everyone.

     

     

     

    #29434
    Avatardefactoman
    Participant

    My current solution to this is to mark the server.cfg on the desktop system as immutable with “CreateDisplay 0” set.  NoMachine thankfully handles this without user interrupting errors.  However this comes at an obvious cost that I can’t make changes on the fly using the GUI and who knows what other side effects down the road.

     

    Hopefully there is some way to avoid this,  but if someone else is seeing this, it’s an option.

     

     

    #29438
    Avatarbrotech
    Participant

    Hello,

    it should be noted that this ‘create display’ feature should be intended as a fallback for those cases when it is not possible to detect a graphical session running on the server.
    Having a Desktop Manager installed and running correctly should make this fallback unnecessary.

    As for the “Always create a new display on this server” checkbox, we agreed that such choice should be remembered on client side (and for the specific user) without causing any modification
    of the cfg file on the server. Related FR: https://www.nomachine.com/FR09R04022

    #29502
    Avatardefactoman
    Participant

    Yea the situation I find myself in is not ideal.   The problem is i’m using Gnome Desktop with CentOS 7.  I have a timer to automatically log out the user when the it’s been idle for an hour.  The problem is some of the time when it does this, a session never becomes available again.

    My only workaround has been to use “systemctl set-default multi-user.target” to turn off the gnome at boot (no local desktop).  Once I do this, NoMachine recognizes that gnome isn’t working, and does its thing.  This actually works great since I have users logging on and off all day.

    I can’t tell if this is a gnome issue or a NoMachine not liking the way gnome logs me out.   I’ll peruse with support if I decide to move forward with this and purchase the evaluation.   I have a knowledge deficit in the area of how NoMachine works with Gnome on CentOS.   “gdm” is running and gnome desktops load, but apparently…no sessions available.  I figured this would be enough to be configured correctly, but alas it is not.

     

    No session data is being developed, because no desktops are available.

    No logs are being generated in the /usr/NX/var/log that have any clues as to why no sessions are being generated.

     

    So in the end, im back to simply letting NoMachine start its sessions, and locking down server.cfg.

     

     

    #29609
    AvatarMth
    Contributor

    Hello

    There are not any known outstanding problems with access to Login Window on CentOS with gdm right now. The worst case would be if it was virtual machine and login window running on Wayland. In this case I would suggest disabling Wayland.

    If there are no warnings/errors generated in the nxserver.log file this may be either something in the configuration or with the xserver.

    The configuration thing to check would be:

    sudo /etc/NX/nxserver --userlist

    The entries there should show if any user has “Screen sharing” or “Access” disabled. If the user “gdm” has this disabled it may prevent anyone from seeing Login Window session.

    If there is nothing helpful there, please gather logs and send them to us. Please follow the article on how to enable debug:

    https://www.nomachine.com/DT10O00163 (“How to gather debug logs for support requests”)

    Then please do:

    sudo /etc/NX/nxserver --restart

    and reproduce the problem when user does not see the Login Window session. Please gather the logs either manually or by executing:

    sudo /etc/NX/nxserver --debug --collect

    Please send the logs to forum[at]nomachine[dot]com using the title of this forum’s thread as the mail’s subject.

    Also what method are you using for logging out the inactive user? Any native method or some script?

    /Mth

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

You must be logged in to reply to this topic.