Update manager

Questions about applications and software
Forum rules
Before you post please read how to get help
User avatar
Pjotr
Level 21
Level 21
Posts: 13746
Joined: Mon Mar 07, 2011 10:18 am
Location: The Netherlands (Holland)
Contact:

Re: Update manager

Post by Pjotr » Sun Jul 01, 2018 9:31 am

gm10 wrote:
Sun Jul 01, 2018 7:27 am
Pjotr wrote:
Sat Jun 30, 2018 5:13 am
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. :mrgreen:

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.
Tip: 10 things to do after installing Linux Mint 19.2 Tina
Keep your Linux Mint healthy: Avoid these 10 fatal mistakes
Twitter: twitter.com/easylinuxtips
All in all, horse sense simply makes sense.

gm10
Level 19
Level 19
Posts: 9738
Joined: Thu Jun 21, 2018 5:11 pm

Re: Update manager

Post by gm10 » Sun Jul 01, 2018 10:54 am

Pjotr wrote:
Sun Jul 01, 2018 9:31 am
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.
Tune up your LM 19.x: ppa:gm10/linuxmint-tools

User avatar
Pjotr
Level 21
Level 21
Posts: 13746
Joined: Mon Mar 07, 2011 10:18 am
Location: The Netherlands (Holland)
Contact:

Re: Update manager

Post by Pjotr » Sun Jul 01, 2018 11:07 am

@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.
Tip: 10 things to do after installing Linux Mint 19.2 Tina
Keep your Linux Mint healthy: Avoid these 10 fatal mistakes
Twitter: twitter.com/easylinuxtips
All in all, horse sense simply makes sense.

gm10
Level 19
Level 19
Posts: 9738
Joined: Thu Jun 21, 2018 5:11 pm

Re: Update manager

Post by gm10 » Sun Jul 01, 2018 11:19 am

Pjotr wrote:
Sun Jul 01, 2018 11:07 am
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?
Tune up your LM 19.x: ppa:gm10/linuxmint-tools

User avatar
xenopeek
Level 24
Level 24
Posts: 24134
Joined: Wed Jul 06, 2011 3:58 am
Location: The Netherlands

Re: Update manager

Post by xenopeek » Sun Jul 01, 2018 11:22 am

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

gm10
Level 19
Level 19
Posts: 9738
Joined: Thu Jun 21, 2018 5:11 pm

Re: Update manager

Post by gm10 » Sun Jul 01, 2018 11:25 am

xenopeek wrote:
Sun Jul 01, 2018 11:22 am
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.
Last edited by gm10 on Sun Jul 01, 2018 12:15 pm, edited 2 times in total.
Tune up your LM 19.x: ppa:gm10/linuxmint-tools

User avatar
Pjotr
Level 21
Level 21
Posts: 13746
Joined: Mon Mar 07, 2011 10:18 am
Location: The Netherlands (Holland)
Contact:

Re: Update manager

Post by Pjotr » Sun Jul 01, 2018 11:28 am

gm10 wrote:
Sun Jul 01, 2018 11:19 am
Pjotr wrote:
Sun Jul 01, 2018 11:07 am
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.
Tip: 10 things to do after installing Linux Mint 19.2 Tina
Keep your Linux Mint healthy: Avoid these 10 fatal mistakes
Twitter: twitter.com/easylinuxtips
All in all, horse sense simply makes sense.

gm10
Level 19
Level 19
Posts: 9738
Joined: Thu Jun 21, 2018 5:11 pm

Re: Update manager

Post by gm10 » Sun Jul 01, 2018 11:34 am

Pjotr wrote:
Sun Jul 01, 2018 11:28 am
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.
Last edited by gm10 on Sun Jul 01, 2018 12:15 pm, edited 1 time in total.
Tune up your LM 19.x: ppa:gm10/linuxmint-tools

User avatar
Pjotr
Level 21
Level 21
Posts: 13746
Joined: Mon Mar 07, 2011 10:18 am
Location: The Netherlands (Holland)
Contact:

Re: Update manager

Post by Pjotr » Sun Jul 01, 2018 11:39 am

gm10 wrote:
Sun Jul 01, 2018 11:34 am
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....
Tip: 10 things to do after installing Linux Mint 19.2 Tina
Keep your Linux Mint healthy: Avoid these 10 fatal mistakes
Twitter: twitter.com/easylinuxtips
All in all, horse sense simply makes sense.

User avatar
karlchen
Level 20
Level 20
Posts: 11418
Joined: Sat Dec 31, 2011 7:21 am
Location: Germany

Re: Update manager

Post by karlchen » Sun Jul 01, 2018 11:46 am

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.
Image
Linux Mint 19.2 32-bit xfce Desktop, Total Commander 9.22a 32-bit
Haß gleicht einer Krankheit, dem Miserere, wo man vorne herausgibt, was eigentlich hinten wegsollte. (Goethe)

gm10
Level 19
Level 19
Posts: 9738
Joined: Thu Jun 21, 2018 5:11 pm

Re: Update manager

Post by gm10 » Sun Jul 01, 2018 11:49 am

Pjotr wrote:
Sun Jul 01, 2018 11:39 am
[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.
Tune up your LM 19.x: ppa:gm10/linuxmint-tools

User avatar
thx-1138
Level 7
Level 7
Posts: 1923
Joined: Fri Mar 10, 2017 12:15 pm
Location: Athens, Greece

Re: Update manager

Post by thx-1138 » Sun Jul 01, 2018 11:59 am

...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...

User avatar
dave8671
Level 3
Level 3
Posts: 141
Joined: Sat Jul 23, 2016 7:04 pm

Re: Update manager

Post by dave8671 » Sun Jul 01, 2018 12:42 pm

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

gm10
Level 19
Level 19
Posts: 9738
Joined: Thu Jun 21, 2018 5:11 pm

Re: Update manager

Post by gm10 » Sun Jul 01, 2018 12:57 pm

dave8671 wrote:
Sun Jul 01, 2018 12:42 pm
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.
Tune up your LM 19.x: ppa:gm10/linuxmint-tools

User avatar
dave8671
Level 3
Level 3
Posts: 141
Joined: Sat Jul 23, 2016 7:04 pm

Re: Update manager

Post by dave8671 » Mon Jul 02, 2018 9:36 am

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.

User avatar
dave8671
Level 3
Level 3
Posts: 141
Joined: Sat Jul 23, 2016 7:04 pm

Re: Update manager

Post by dave8671 » Sat Aug 18, 2018 12:24 pm

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
Level 19
Level 19
Posts: 9738
Joined: Thu Jun 21, 2018 5:11 pm

Re: Update manager

Post by gm10 » Sat Aug 18, 2018 1:03 pm

dave8671 wrote:
Sat Aug 18, 2018 12:24 pm
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.

User avatar
dave8671
Level 3
Level 3
Posts: 141
Joined: Sat Jul 23, 2016 7:04 pm

Re: Update manager

Post by dave8671 » Sat Aug 18, 2018 1:31 pm

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
Level 19
Level 19
Posts: 9738
Joined: Thu Jun 21, 2018 5:11 pm

Re: Update manager

Post by gm10 » Sat Aug 18, 2018 1:51 pm

dave8671 wrote:
Sat Aug 18, 2018 1:31 pm
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.

User avatar
Pjotr
Level 21
Level 21
Posts: 13746
Joined: Mon Mar 07, 2011 10:18 am
Location: The Netherlands (Holland)
Contact:

Re: Update manager

Post by Pjotr » Sat Aug 18, 2018 2:31 pm

gm10 wrote:
Sat Aug 18, 2018 1:51 pm
dave8671 wrote:
Sat Aug 18, 2018 1:31 pm
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.... :lol:
Tip: 10 things to do after installing Linux Mint 19.2 Tina
Keep your Linux Mint healthy: Avoid these 10 fatal mistakes
Twitter: twitter.com/easylinuxtips
All in all, horse sense simply makes sense.

Post Reply

Return to “Software & Applications”