Offline/Remotely changing Trust of .desktop file


(Arffeh) #1

Hello,

I’ve made a small script for provisioning a lubuntu 19.04 installation into a working state (create user profiles, harden services, uninstall cruft, install additional applications, place a few config files and create a few desktop shortcuts).

The desktop shortcuts are copied from /usr/share/applications/ .

After looking through many forum/github topics regarding the trust principles stored in gvfs::metadata, I set out to try and apply the trust as part of provisioning.

However as the script isn’t obviously a GUI user logged into the computer, it seems metadata isn’t writeable.

I was wondering if anyone had a method of modifying metadata in this manner? (the user might currently be using the workstation, they might be logged out, the state at the time would be unknown).

A few choice threads I’ve read:


(Pedram Pourang) #2

I’m not sure if I understood your question but to set the trust metadata from command-line, you could use:

gio set FILE_PATH -t string metadata::trust "true"

And to unset it:

gio set FILE_PATH -t unset metadata::trust

See man gio.

Of course, the metadata are set by user. They aren’t global properties; they’re saved in /home/USER_NAME/.local/share/gvfs-metadata.


(Arffeh) #3

Unfortunately it seems metadata cannot be written if it isn’t done by the the user, logged into the GUI, doing it in a terminal.

I’m asking if it can be done remotely via CLI. :slight_smile:


(Pedram Pourang) #4

Command-line, yes; as another user, no.


(Arffeh) #5

After attempting it remotely via SSH on a fresh install, after using su to become the correct user, I get:

gio: Setting attribute metadata::trust not supported

There was a SO question (which now eludes me) mentioning something about gvfs/dbus needing to be available (which generally is when physically logging into the computer) before metadata is allowed to be written.


(Pedram Pourang) #6

https://wiki.gnome.org/Projects/gvfs/doc


(Arffeh) #7

Thanks heaps for pointing me in the right direction.

root@test:/root# su -l -g user user -s '/bin/bash' -c 'export `dbus-launch`;gio set /home/user/Desktop/example.desktop -t string metadata::trust "true"'

It doesn’t seem to achieve the desired effect. gio is no longer throwing a warning, not sure if that’s better or worse. :slight_smile:

Things of note, I see “export `dbus-launch`” correctly start under the user (which never dies, but that’s a problem for another day).


(Pedram Pourang) #8

What about dbus-run-session -- (see man dbus-run-session)?

P.S. Since I’ve never needed to set gvfs metadata remotely, your tests are interesting to me. The results might be helpful to others too.

NOTE: You could use lxsudo if you have its latest version.

NOTE 1: When you see the contents of a remote folder in pcmanfm-qt, they won’t be updated automatically on changing their gvfs metadata; you need F5.


(Arffeh) #9

I agree the results may be helpful to others. I’ve been banging my head against a wall regarding this for more time than I care to admit. :slight_smile: At this point after a fair bit of trial and error, googling for people having similar problems (found basically nothing), I finally gave in and decided to ask for some advice from people who know better :wink:

I do all commands without the test user being logged in. I verify a success or fail by then logging in to see if the change was made.

dbus-run-session is far more verbose, which is nice:

root@test:/root# su -l -g user user -s '/bin/bash' -c 'dbus-run-session -- gio set /home/user/Desktop/example.desktop -t string metadata::trust "true"'
dbus-daemon[3359]: [session uid=1001 pid=3359] Activating service name='org.gtk.vfs.Daemon' requested by ':1.0' (uid=1001 pid=3360 comm="gio set /home/user/Desktop/example.desktop -t str" label="unconfined")
dbus-daemon[3359]: [session uid=1001 pid=3359] Successfully activated service 'org.gtk.vfs.Daemon'
dbus-daemon[3359]: [session uid=1001 pid=3359] Activating service name='org.gtk.vfs.Metadata' requested by ':1.0' (uid=1001 pid=3360 comm="gio set /home/user/Desktop/example.desktop -t str" label="unconfined")
fusermount: failed to access mountpoint /home/user/.cache/gvfs: Permission denied
dbus-daemon[3359]: [session uid=1001 pid=3359] Successfully activated service 'org.gtk.vfs.Metadata'
A connection to the bus can't be made

‘user’ is in fact uid 1001 gid 1001, so that’s progress. I did have concerns with the earlier method that the invoking environment might get mixed in with it, hence forcibly using way more su parameters than probably needed to ensure the environment was clean.

EDIT: Did a reboot and re-ran, I was still greeted with the above error, however it also emitted the following line:

** (process:935): WARNING **: 15:25:19.971: Failed to connect to the D-BUS daemon: Could not connect: Connection refused (g-io-error-quark, 39)

Possibly a side effect of never having a user login after reboot?


(Pedram Pourang) #10

I did it with VirtualBox + Manjaro after creating a test user and got the same result but without the last one (Failed to connect to the D-BUS daemon: Could not connect: Connection refused (g-io-error-quark, 39).


(Pedram Pourang) #11

The ridiculous thing is that, in spite of those messages, it really worked! I saw that after logging into the test user. To be sure, I unset the trust metadata in the same way and it worked again.

I have no idea why it is so. According to the Gnome doc, it should work and it did here but why showing error messages?!


(Arffeh) #12

That’s intriguing. Something must be different between environments, as my .desktop isn’t getting the trust metadata set on lubuntu 19.04.

I’ve tailed the entire /var/log/ directory while running the above command to try and find any valuable output, however nothing shows (except the su log success entries in auth.log).

Did you ssh as the test user directly, or ssh in as a privileged user and use su/sudo to run as the test user?


(Alf Gaida) #13

To put it mild - we can’t support Lubuntus trust system here - and we don’t want to. They changed something, we don’t know what and we will not have a look. Easy as can be.

Marked as solved. For further questions use ubuntu ressources.
@tsujan: Do you remember the “blackmailing” attempt: If you don’t change the metadata variable the way we (pluralis majestatis) wan’t it, we will change it downstream - so be it, we as project don’t have any saying in questionable downstream decisions :smiley:


(Pedram Pourang) #14

There may be a misunderstanding.

I just wanted to know whether metadata could be changed without logging in as the test user (because, according to Gnome doc, it should). So, I tried to do so with su (and with a command similar to yours) as a privileged user and without logging in as the test user.

The terminal output was the same as in your case. The messages made me retry until I got tired and logged in as the test user, seeing that the metadata was really changed. Then, I repeated the same procedure to unset it and it was unset.


(Arffeh) #15

Sure thing. I had initially thought it was lxqt, turns out it wasn’t. I appreciate the assistance pointing me somewhere else. Sorry for being incorrect. I’ll hunt down the answers either with ubuntu or the gvfs project.


(Alf Gaida) #16

Anyways - the question should be: Does it work with Manjaro or Debian - all things fine - if not: We had to evaluate.


(Pedram Pourang) #17

@agaida I was just curious about metadata and what Gnome doc said. “trust” is only one example. It shouldn’t make any difference if one sets “trust” or any other metadata without logging in as the user who owns them.


(Arffeh) #18

@tsujan @agaida It’s fine guys, no arguing needed please.


(Alf Gaida) #19

For me it works fine :smiley:

Sample: as logged in user

  • copy a certain desktop file to the desktop - say midori.desktop
  • gio info midori.desktop
  • gio set midori.desktop metadata::trust true
  • pkill -SIGHUP pcmanfm-qt
  • gio set midori.desktop metadata::trust false
  • pkill -SIGHUP pcmanfm-qt

Next step: do it over ssh


(Pedram Pourang) #20

Yes but the question was, “what if we don’t log in as that user?” That answer I got: “we can still change the metadata of the user.”