How to allow caja to manage desktop in a root-user session?

[ghostplant]

When logged in as a root-user, mate-session doesn't boot caja to manage the desktop background.

I have to manually run caja -n --force-desktop to make it take over the desktop, but it is not a stable solution since sometimes a random, improper orders of mate-settings-daemon / macro / caja (with manual force desktop) will make caja fail to take over the desktop but fall into hang status, or weird theme applied.

[L-U-T-i]

Despite all considerations and discussions (even here...), I find it sometimes convenient to login as root as well. If gnome and other desktop managers support it, I really don't see a reason mate desktop should take care about our own safety more than he'd actually like to. All this just to avoid repeating the discussion about our reckless acts... ;-)

So, to get it, I partially revert the commit 9e5ea15 (from 08.10.2016): sed -i 's|if (running_as_root () \|\| !running_in_mate ())|if (!running_in_mate ())|g' src/caja-application.c sed -i 's|if (running_in_mate () && !running_as_root())|if (running_in_mate ())|g' src/caja-application.c

Besides, I make also a mate-submodules issue 'It seems switching to libegg submodules breaks saving of applications state for root session #16' quick fix: sed -i 's|if (geteuid () == 0 \|\| !running_in_mate ()){|if (!running_in_mate ()){|g' mate-submodules/libegg/eggsmclient.c

before building caja.

Hope it helps.

[lukefromdc]

Easy way (just tested it in wayland but nothing should change outside of a normal MATE session) is to invoke sudo caja --force-desktop in a user session other than MATE or presumably same without sudoin a root session.

To make this work in a root MATE session requires another step: you would need to (in the root session) open dconf-editor and go to org->mate->desktop->session->required-components and change file-manager from'caja' to ''that is set a custom value of an empty line. Then log out and back in, and invoke caja from the terminal. You need to do this so you can start a new instance of caja with --force-desktop rather than connect to the existing instance. That in turn could be added to a startup script to start it automatically.

The reason we don't manage the desktop by default in a root session is because otherwise running caja as root in a normal session would take over the desktop, which was a nuisance bug in Nautilus's GNOME 2 days.

[ghostplant]

Great! Can those changes merged into caja code base? At least an dconf option allowing users to enable. I know the way of --force-desktop. However, it is hard to autostart in correct order with other components like marco and mate-settings-daemon. An incorrect autostart order if unlucky makes caja display fonts weird and problematic.

[ghostplant]

I use lightdm-gtk-greeter to login MATE session with root user, so what's why I need a stable method to launch caja once logged in. I tried adding a booting app in /etx/xdg/autostart, however, it cannot ensure launching orders with MATE modules so that caja's theme is not applied.

[lukefromdc]

You are getting pretty far out from how the session is normally used and out of my experience range. Note that this is an unsupported use case, I don't see us writing new code to support it

[L-U-T-i]

@lukefromdc

The reason we don't manage the desktop by default in a root session is because otherwise running caja as root in a normal session would take over the desktop, which was a nuisance bug in Nautilus's GNOME 2 days.

I'm not sure how to understand that ("take over the desktop" - what exactly do you mean by that, or how is it manifested)?

If I have one VNC session as a normal user and another VNC session as root (at the same time), I can launch from normal user terminal 'sudo caja' getting a new caja window with "running as superuser" in the titlebar. Or, I get the same simply through a right click "Open as Administrator". I am using that from time to time (with my patched build as above) since years, and haven't noticed anything weird by now...

[ghostplant]

I use MATE as the desktop environment of local PC. While I always prefer to enable root login permission and login desktop with root user. Since Ubuntu 20.04, MATE caja is no longer allowed to start and display desktop icons, so I have to use --force-desktop manually run it eveytime which is hard to automatic but to manually launch it in terminal. In Ubuntu 18.04, MATE caja works perfectly without any issues for a root session. So no idea why it is disabled and now become troublesome for root-session users.

[lukefromdc]

By "take over the desktop" I mean render a root desktop on top of the user desktop, a bad habit GNOME 2 Nautilus once had when invoked with sudo by a user. If we only looked for the MATE session when determining whether to run the desktop by default, a root instance of caja would pickup the session name and always manage the desktop, bringing back that old bug. That is the reason caja was changed to avoid the root case for managing the desktop by default.

[L-U-T-i]

Render a root desktop on top of the user desktop means I should have a "root's Home" icon (directory launcher) and other root's desktop icons (custom desktop items) displayed on my desktop? Together with my own (user) icons, or over them (so I see only root's items)? I am not noticing anything like that (launching "sudo caja" from my user's terminal prompt).

Or, shall this happen if I launch "sudo caja --force-desktop" from my terminal (and not just "sudo caja")? As I really don't see a reason (or a need) to do that (unless I would maybe want exactly that).

[lukefromdc]

That may differ between sudo caja and su followed by caja but I did in fact see root's home AND my normal icons with sudo caja.

[L-U-T-i]

Interesting. I don't see absolutely any change on my desktop (no any root's Desktop items appeared) when I launch a new caja browser window with "sudo caja".

[lukefromdc]

Without --force-desktop you would not and should not

[L-U-T-i]

But why would I even want to launch "sudo caja --force-desktop" as normal user?! What would I like to get through that (or, why would I need that)? If I need to browse (and do some changes) as a privileged user, I get a root browser window with "sudo caja", and I can do watever I want with that. I can browse also root's home and Desktop directory.

I really can't see a reason to try to mess with my user's desktop using that option.

I think what would really make sense is to disable the "--force-desktop" option (or, generally managing user's desktop) if caja tries to be launched with elevated privileges (as any other user as currently logged in one), but definitely not to manage desktop if launched as a root (or, generally as any other) user already logged in or just logging in.

[ghostplant]

Maybe a better question is: how to let caja --force-desktop to be an autostarted application, but that autostart plan should be postponed until both macro and mate-settings-daemon are completed to start. How to achieve that?

In non-root login session, it is not a problem since caja is naturally auto-launched by mate-session-manager just after user login in order to show desktop icons.

[lukefromdc]

I would use a single script to start caja and anything I wanted to start before or after it in a particular order. In the new wayland session I use a single script started by the compositor's own autostart function to start everything else.

[lukefromdc]

I am not going to disable the use of the --force-desktop option under any condition.

[ghostplant]

I tried that in the past and drop mate-session-manager, which doesn't work.

mate-settings-daemon &
caja --force-desktop &

It just ensures the initialization startup to be ordered, but cannot ensure the initialization completion to be ordered. I still 50% possiblity get caja desktop icons not rendered by mate-settings-daemon.

[lukefromdc]

Anyway, I don't see us investing time in supporting root sessions, just as I don't see us trying to disable it either. We are a small team with zero paid staff.

Set up whatever works best for your use case, and feel free to publish your work for the benefit of others with similar needs.

[ghostplant]

OK, maybe I can try @L-U-T-i 's suggestion, I'll recompile and apply that change to test if it works well.