Update manager

[dave8671]

Is the issue with the update manager regrading home permissions fixed in Linux Mint 19?

[karlchen]

Hello, dave8671.

I assume you should explain in a few more details what precisely the update manager regrading home permissions refers to and means. Also you should explain which Linux Mint release(s), alledgedly, are affected.
I have never found any symptom that the Linux Mint Update Manager had fiddled around with permissions in my home directory, not on Mint 13, not on Mint 17/17.1/17.2, not on Mint 18.1.

Best regards,
Karl

[Pjotr]

There does appear to be an issue with home permissions in Update Manager in LM 19.

I've had a conversation about this with forum member Cosmo., who is unfortunately no longer active on this forum. Apparently, when updating/refreshing automatically (not when updating/refreshing manually!) UM changes the ownership of ~/.dbus and ~/.gvfs into root. Also, when updating/refreshing (for which it needs no password authentication), it creates the file ~/sudo_as_admin_successful, which might indicate the presence of an undocumented security backdoor.

Cosmo. wrote (in German, use Google Translate if you need it in another language):

LM 19 hat dagegen ganz andere und wirkliche Killer Bugs. Stichworte: DBus und GVFS. Die Entwickler haben es tatsächlich geschafft, den 2 Jahren alten Fehler, daß der Update Manager Objekte mit falschem Besitzer erzeugt (~/.cache/dconf/user), so zu verschlimmbessern, daß DBus und GVFS auf Benutzerebene nach einiger Zeit nicht mehr richtig funktionieren werden.

Laß UM sich selbst automatisch auffrischen, das passiert standardmäßig nach 10 Minuten. Guckst du jetzt in dein Home, siehst du ~/.dbus im root-Besitz. Das passiert übrigens nicht, wenn du UM manuell auffrischst. An den Zeiteinträgen für .dbus und .cache/dconf läßt sich erkennen, daß beide dieselbe Ursache haben.

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.

Ist GVFS somit auch erfolgreich korrumpiert, können die merkwürdigsten Dinge passieren. Zum Beispiel: Öffne ich in ~/.cache ein Nemo-Fenster (Rechts-Klick Menü) als root, öffnet dieses nicht diesen Ordner, sondern zeigt mir statt dessen /root an. Bei ~ oder anderen Unterordnern passiert das (noch?) nicht.

ich habe in den Blog-Kommentaren nicht gefunden, daß irgend jemand bereits auf diese Probleme aufmerksam gemacht hätte. Ich frage mich allerdings bei der einen oder anderen Bug-Meldung, ob nicht Probleme mit DBus oder GVFS dahinter stecken. Es ist ganz klar, daß grafische Linux-Systeme auf beides zurückgreifen müssen und ein Versagen weitreichende Konsequenzen haben kann.

Ich habe auch den Eindruck, daß UM selbst zum Sicherheitsrisiko geworden ist. Nicht wegen der Änderungen, wie sie angekündigt sind, sondern wegen dem, was im Untergrund passiert. UM erzeugt beim Auffrischen nämlich auch die Datei ~/sudo_as_admin_successful. Hoppla, wie kann sudo erfolgreich funktionieren, wenn gar keine Paßwortabfrage stattfand? Die Objekte im root-Besitz zeigen jedoch, daß sudo tatsächlich erfolgreich war. Was für eine undokumentierte Hintertür wird da benutzt?

[karlchen]

Hi, Pjotr.

I see. The "weirdness" which here on my Linux Mint 18.1 seems to affect ~/.cache/dconf/user only (owned by root) has been made to work "more prefectly" in Mint 19. So the issue has received a wider scope now and may cause more trouble in future.
I admit that I had not followed progress or regression during the Mint 19 beta phase too closely.
Had preferred to have closer looks at Ubuntu 18.04 Mate and Xubuntu 18.04.
So dave8671's post seems to have been about Linux Mint 19 beta/release very likely.

Regards,
Karl

[Pjotr]

If anyone wishes to test: you can reset the home permissions to how they should be, like this:

Code: Select all

sudo chown -R $USER:$USER $HOME

.... which should allow you to observe when things go wrong again (namely after the first scheduled automatic refresh of UM).

[Sir Charles]

Was für eine undokumentierte Hintertür wird da benutzt?

What kind of undocumented backdoor is used?

(translated by Google)

Is this reason to be concerned? What are the implications of~/.cache/dconf/userbeing owned by root?

[Pjotr]

It's about disrupting/corrupting the way that the system works. This undesirable behaviour of UM might create malfunctions. Especially in Mint 19, where the problem has spread to ~/.dbus and (under certain circumstances) to ~/.gvfs.

Probably a polkit issue....

The "backdoor" is only a suspicion, based on the appearance of the file ~/sudo_as_admin_successful after an action (refreshing UM) which doesn't require a password. No proof.

The devs have already been notified by xenopeek.

[Sir Charles]

It's about disrupting/corrupting the way that the system works. This undesirable behaviour of UM might create malfunctions. Probably a polkit issue....

Thanks Pjotr!
Just the mention of "backdoor" seems to be enough to put one on alert. So there are no security issues involved here?

[Pjotr]

It's about disrupting/corrupting the way that the system works. This undesirable behaviour of UM might create malfunctions. Probably a polkit issue....

Thanks Pjotr!
Just the mention of "backdoor" seems to be enough to put one on alert. So there are no security issues involved here?

The "undocumented backdoor" is only a suspicion, based on the creation of the file ~/sudo_as_admin_successful after an action (refreshing UM) which doesn't require a password. No proof....

[Sir Charles]

Alright, good to know. Thanks again!
By the way I just found that the issue had been reported by Cos-mo on GitHub, issue 169, already on Aug 23, 2016. I am going to read up on it a bit.

[Pjotr]

Alright, good to know. Thanks again!
By the way I just found that the issue had been reported by Cos-mo on GitHub, issue 169, already on Aug 23, 2016. I am going to read up on it a bit.

Yes. But the issue has spread and become worse, in Mint 19....

Note that this spreading and worsening of the issue in Mint 19, was also noticed by Cosmo. and brought to my attention by him. He has full credits for this.

[Sir Charles]

Yes. But the issue has spread and become worse, in Mint 19....
Note that this spreading and worsening of the issue, was also noticed by Cosmo. and brought to my attention by him. He has full credits for this.

Yes, it sure has. And he sure should get the credit for having raised the flag already back then. A bit odd that the issue hasn't been addressed for such a long time an now it is present in LM 19 as well. And it's too bad that it's worse.

Thanks for the exchange, fascinating stuff! BTW, pity that Cosmo hasn't been around for such a long time. I am sure many forum members miss him. I sure do.

Cheers
Marziano

[dave8671]

I had this issue with my t520 and I had to reinstall since the fix I read did nothing and it got worse. I offer Mint as a option to windows and most like it. My issue post was below I fixed it the only way I could with a reinstall. I have one client that has 18.3 installed and I instructed him to only update though the shell which is what I have been doing and the permissions issue has not shown itself so far on my laptop. Think I am going to wait on a fixed before offering Mint to new users since this could be a negative view that want to switch.


viewtopic.php?f=211&t=270490&p=1479736& ... e#p1479736

[Pjotr]

I must say that after repairing permissions earlier today with sudo chown -R $USER:$USER $HOME, the permissions are still correct in my Mint 19. Even though I've rebooted my computer several times, which each time should have triggered an automatic mintupdate refresh after 10 minutes....

Could this already have been solved by an update?

The suspicious creation of the file ~/.sudo_as_admin_successful is still there, though....

[xenopeek]

I have a hard time reliably reproducing this. I stumbled on the same issue on a fresh install. After doing like Pjotr — changing ownership back --- I couldn't manage to reproduce it. Even switching to a new user account or deleting .dbus or .cache/dconf directories in home didn't make the issue reappear.

But just now it did reappear. It may be related to first mintupdate refresh after boot? I deleted the .dbus and .cache/dconf directories again but now can again now manage to reproduce. The directories aren't being recreated. This is a headscratcher Can't find the exact steps to reproduce the issue at command...

[Pjotr]

Cosmo. also reported unreliable reproduction of the bug to me:

Ich habe es hier im Testsystem soeben noch einmal überprüft. Allerdings mit 2 Unterschieden: 1. Ändere ich nicht den Besitzer mit chown, sondern lösche die besagten Objekte (warum auch nicht, wenn die Ordner mit root als Besitzer einmal erstellt wurden, können sowieso keinerlei Dateien darin vom Besitzer erstellt werden, also gibt es nichts zu verlieren), 2. habe ich zuvor die automatische Aktualisierung für UM auf 2 Minuten initial und 1 Minute Wiederholung geändert. Es passiert tatsächlich nicht wirklich jedesmal, sondern in vielleicht 8 von 10 Fällen. Unzuverlässigkeit, wohin das Auge blickt.

Also, he remarks (correctly, in my opinion) that sudo without asking for password shouldn't happen in the first place, let alone successful:

Die Erstellung der sudo_as_admin_successful-Datei kann aber bereits als Hinweis dienen, daß alles beim Alten = beim Argen liegt, denn sudo ohne Paßwortbfrage darf ganz einfach nicht passieren, und schon gar nicht erfolgreich.

Not very encouraging, all this....

There does some to be one remarkable difference, though: as said, I didn't remove the root-owned files, but used chown to make them the property of the user (me). Which apparently, so far, has prevented the bug from re-appearing.... But it's far too early to tell whether this difference has any significance.

[xenopeek]

On a fresh install the ~/.dbus and ~/.cache/dconf directories don't exist on first login. After 10 minutes they appear to be created by the first run of mintupdate auto-refresh and get owner by root. Logout/login doesn't solve it. After changing ownership of both to the user this does not appear to reoccur.

The ~/.sudo_as_admin_succesful also appears to be created by mintupdate. It gets created both for auto-refresh and (after deleting the file) manually clicking the Refresh button in mintupdate.

Not clear on how the ~/.gvfs (for user mounted virtual filesystems) plays into mintupdate. I think it doesn't.

[Pjotr]

Root ownership of ~/.gvfs and ~/.cache/doc appears to be a side effect of launching Nemo as root by means of a right-click, after ~/.dbus and ~/.cache/dconf have been changed to root ownership. So it's not a direct effect, but might be an indirect effect.

This is what Cosmo. reports:

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.

On at least one of my machines, ~/.gvfs and ~/.cache/doc have been changed to root ownership without such a previous Nemo action. So apparently this can also be triggered by other means.

For the time being it might be an acceptable workaround to chown them all back to the right ownership, 11 minutes after first installation of Mint.... If that's a practical emergency measure that works predictably well, I'm all for it.

In summary: it appears we have found both a bug and a design flaw. An inconsistently reproducible bug that creates root ownership, and a consistently reproducible design flaw in mintupdate that's responsible for the creation of ~/.sudo_as_admin_successful.

[xenopeek]

I'm not clear on that it matters any that ~/.cache/dconf is owned by root. If you google that issue you find multiple programs that can cause this.

According to one of the devs the ~/.gvfs directory resets after logout/login.

[gm10]

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 does not display a certain message.

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.