Update manager

[Pjotr]

it creates the file ~/sudo_as_admin_successful, which might indicate the presence of an undocumented security backdoor.

I'll stay out of this thread because it seems like much ado about nothing but since nobody cleared this up and before somebody actually believes it I think I should say this:

The .sudo_as_admin_successful file is just a flag for the .bashrc script to pick up on so bash.

This is linux, it's open source, you can check the actual code before starting baseless conspiracy theories, or ask somebody who understands how it works. You have a certain standing in the community due to your guides and activity here, it doesn't look good on you. Just my 2c.

Cents received with gratitude.

Note from the cautious wording of my statement ("might indicate"), that my intention is not to participate in any conspiracy theory.

It's sincere puzzlement, based on the current behaviour of mintupdate, which creates (without asking for password!) root-owned files in my /home. Which is definitely wrong. Among other things this raises security concerns for me, because if mintupdate can do "sudo as admin" without password authentication, that route might perhaps be exploitable by others.

I don't blame the developers: after all, sh** happens and people can make mistakes. I'm not here to fight or to quibble; I only want clarity in this matter (and hopefully workarounds and fixes for any bugs). As such, the technical gist of your comment is welcome and helpful.

[gm10]

It's sincere puzzlement, based on the current behaviour of mintupdate, which creates (without asking for password!) root-owned files in my /home. Which is definitely wrong. Among other things this raises security concerns for me, because if mintupdate can do "sudo as admin" without password authentication, that route might perhaps be exploitable by others.

I don't blame the developers: after all, sh** happens and people can make mistakes. I'm not here to fight or to quibble; I only want clarity in this matter (and hopefully workarounds and fixes for any bugs). As such, the technical gist of your comment is welcome and helpful.

Fair enough. There is neither mistake nor mystery. Let me try to explain it after all:

You are correct, by default you need a password to call sudo. However, mintupdate has an exemption defined in /etc/sudoers.d/mintupdate. That's no secret backdoor, it's standard sudo functionality, you can exempt your own programs there if you want to. That file, as well as all files belonging to mintupdate, are owned by the root user, so to modify them you need to have root privileges already.

As to programs run as root via sudo creating files owned by root, that's just what happens. Compare the output of these and you'll see:

Code: Select all

touch test; ls -l test; rm -f test

Code: Select all

sudo touch test; ls -l test; rm -f test

However, since programs run via sudo in a root context can of course access root owned files, they don't mind.

Hope that clears things up.

[Pjotr]

@gm10: thanks for your explanation.

That means that the creation of the file ~/sudo_as_admin_successful is no problem after all. That's good news, because that means that there's no security issue.

As to the creation of a root-owned ~/.dbus (which is only irregularly reproducible), there does appear to be a problem. Because that can cause DBus to stop behaving correctly for the user.

Which in its turn can trigger root ownership of ~/.gvfs and ~/.cache/doc. Especially root ownership of ~/.gvfs seems problematic and undesirable.

[gm10]

As to the creation of a root-owned ~/.dbus (which is only irregularly reproducible), things seem to be different. Because that can cause DBus to stop behaving correctly for the user.

Which in its turn can trigger root ownership of ~/.gvfs and ~/.cache/doc. Especially root ownership of ~/.gvfs seems problematic and undesirable.

The ~/.gvfs even existing is actually somewhat surprising, because the mount point is elsewhere, as it should be:

Code: Select all

$ mount | grep -i gvfs
gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)

Are you running some software that is hardcoded to use ~/.gvfs or what problems are you running into?

[xenopeek]

We could trigger creation of ~/.gvfs by running sudo xed (which you shouldn't of course, but as one way to reproduce it).

[gm10]

We could trigger creation of ~/.gvfs by running sudo xed (which you shouldn't of course, but as one way to reproduce it).

Oh interesting. Which results immediately in

Code: Select all

$ mount | grep -i gvfs
gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
gvfsd-fuse on /home/user/.gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=0,group_id=0)

PS: Seems this happens only the first time you launch a GTK app via sudo after you log in. After unmounting the bad ~/.gvfs mount it won't get re-created even if you sudo other GTK apps. I don't have time to dig into the code that gets this wrong but interesting.

[Pjotr]

As to the creation of a root-owned ~/.dbus (which is only irregularly reproducible), things seem to be different. Because that can cause DBus to stop behaving correctly for the user.

Which in its turn can trigger root ownership of ~/.gvfs and ~/.cache/doc. Especially root ownership of ~/.gvfs seems problematic and undesirable.

The ~/.gvfs even existing is actually somewhat surprising, because the mount point is elsewhere, as it should be:

Code: Select all

$ mount | grep -i gvfs
gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)

Are you running some software that is hardcoded to use ~/.gvfs or what problems are you running into?

Forum member Cosmo. reported this first to me. In German, but he can reproduce this event 8 out of 10 times (so irregularly), after launching Nemo as root by means of a right-click (sometimes only after the second or third attempt, after a new login as user).

On at least one of my machines, ~/.gvfs and ~/.cache/doc have been changed to root ownership without such a previous Nemo action. And also without abusing sudo for launching a graphical app, by the way.... So apparently this can also be triggered by other means (I don't know how).

Here's Cosmo's full report (how's your German?):

Nachdem DBus jetzt nicht mehr richtig für den Benutzer funktioniert, öffne in Nemo per Rechtsklick eine Instanz als root. Und siehe da (manchmal erst beim 2. oder 3. Mal nach erneuter Benutzer-Anmeldung): jetzt gibt es auch noch ~/.gvfs im root-Besitz und außerdem ~/.cache/doc ebenso im root-Besitz (beide wiederum mit gleichem Zeitstempel). - Das System ist übrigens völlig konfus über diese beiden Objekte. Siehst du sie dir mit ls -la an, so zeigt dir das System lauter Fragezeichen an und hat keine Ahnung über die Eigenschaften. Außerdem lassen sich diese Objekte auch mit root-Rechten nicht löschen. Erst nach Abmelden und erneuter Anmeldung bessert sich zumindest das.

[gm10]

Here's Cosmo's full report (how's your German?):

Good enough. Still, it doesn't describe an actual problem. The sudo xed repro I tried (see post above yours) was fully functional. My post above yours also shows why your friend couldn't delete .gvfs - you need to unmount it first:

Code: Select all

sudo umount ~/.gvfs

mintUpdate's only connection to this is making use of sudo for some commands.

[Pjotr]

mintUpdate's only connection to this is making use of sudo for some commands.

Well, according to Cosmo the link is there, albeit indirect.... It's apparently namely a consequence of the previous corrupting of the DBus functionality for the user, caused by the creation of a root-owned ~/.dbus. Which is the doings of mintupdate....

[karlchen]

Hi.

I am not quite sure whether the details which I can add will help identify where the root owned directories and files inside $HOME originate. But here they are:

Code: Select all

$ sudo find $HOME ! -user $USER
[sudo] Passwort für karl: 
/home/karl/.dbus
/home/karl/.dbus/session-bus
/home/karl/.dbus/session-bus/cba3a40d30d346f59281feae192041ed-0
/home/karl/.gvfs

This is on Ubuntu 18.04 xfce, objects created on 14-05-2018, 6 days after the initial installation.

Will give them away to myself now and watch what will happen.

Karl
--
P.S.:
No such root owned biests inside $HOME on Ubuntu 18.04 Mate till now, installed 03-July-2018, and frequently used and updated since.

[gm10]

[Well, according to Cosmo the link is there, albeit indirect.... It's apparently namely a consequence of the previous corrupting of the DBus functionality for the user, caused by the creation of a root-owned ~/.dbus. Which is the doings of mintupdate....

There is nothing in mintUpdate that even interacts with that (I did briefly look at the code). My guess is at best your friend updated a package that did.

[thx-1138]

...hopefully this doesn't add any 'noise' to the thread. In my Mint 18 installation, the root-owned .gvfs folder:

Code: Select all

stat .gvfs
  File: '.gvfs'
  Size: 4096      	Blocks: 8          IO Block: 4096   directory
Device: 802h/2050d	Inode: 53215247    Links: 2
Access: (0700/drwx------)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2018-06-28 20:37:18.009162109 +0300
Modify: 2016-12-06 16:54:15.978785361 +0200
Change: 2016-12-06 16:54:15.978785361 +0200
 Birth: -

System was installed on 24 October 2016, ie. 6 weeks before this was last modified.
However, I'm fairly certain i didn't sudo caja / xed during those 6 weeks...

[dave8671]

After I read this post through I got to wondering about mintUpdate is this a library or the backend for update manager?

[gm10]

After I read this post through I got to wondering about mintUpdate is this a library or the backend for update manager?

mintupdate = Update Manager

One is the name of the executable, the other the menu entry/window title.

[dave8671]

Okay got it... from a user side seems to be hard to find the line of code that is causing this issue since its been 2 years.

[dave8671]

Any more info on the fix? due to the nature of this issue it may not be a easy solution. I am thinking of upgrading to mint 19. Currently I used 18.3 should I use update manager to upgrade or clean install? I have been using the console for updates and no issues with change permissions.

[gm10]

Any more info on the fix? due to the nature of this issue it may not be a easy solution. I am thinking of upgrading to mint 19. Currently I used 18.3 should I use update manager to upgrade or clean install? I have been using the console for updates and no issues with change permissions.

Depends, what is your actual issue? From what I remember from this thread some file ownership may get flipped but I've yet to hear about an actual issue caused by this. As posted by @Pjotr on the first page already, you can change it all back with sudo chown -R $USER:$USER $HOME.

For upgrading your distribution a clean install is always preferable. But it won't solve this issue.

[dave8671]

I did try that command on my laptop which did nothing. Before the reinstall I had a no background and than before I reinstalled the panel vanished this was a few months back. I have had no issues with updated as long as I use the terminal for upgrades on the my current installation. I may wait till 2021. Yes I will be using the terminal for upgrades for a while it seems to avoid the permissions issue.

[gm10]

I did try that command on my laptop which did nothing. Before the reinstall I had a no background and than before I reinstalled the panel vanished this was a few months back. I have had no issues with updated as long as I use the terminal for upgrades on the my current installation. I may wait till 2021. Yes I will be using the terminal for upgrades for a while it seems to avoid the permissions issue.

What do you mean it did nothing? It changes ownership of all the files in your home folder to your user. If that isn't actually what your problem is about then I think we've all been discussing the wrong thing. Is it permissions then rather than ownership?

My problem is that these issues are not happening to me unless I specifically try to launch a GUI application with sudo or run the file browser as admin. And those only flip ownership of that empty ~/.cache/dconf/user file that, which does not seem to affect anything. I can't reproduce it at all with Update Manager. That's why I'm having a hard time giving any advice here.

[Pjotr]

I did try that command on my laptop which did nothing.

What do you mean it did nothing?

In order to avoid such misunderstandings when dealing with (relative) beginners, I usually advise to use the -v handle in such commands....