/usr gehört plötzlich 501.501

Started by ReinerS, 2014/08/19, 13:33:34

Previous topic - Next topic

michaa7

#15
Quote from: der_bud on 2014/08/20, 16:08:05
Inside that .tar.gz file is a /usr-directory dating from July 27 with 501:501 :) (but,to repeat, on that system with that flashplayer my /usr has 0:0, so the flash-update two weeks ago did nothing wrong).

Yes, the same here *when using the update-script*. And looking at the output reveals the culprit gives a hint:
Quotedownloading http://fpdownload.macromedia.com/get/flashplayer/pdc/11.2.202.400/install_flash_player_11_linux.i386.tar.gz ...
verifying checksum install_flash_player_11_linux.i386.tar.gz ...
unpacking install_flash_player_11_linux.i386.tar.gz ...
verifying checksum contents of install_flash_player_11_linux.i386.tar.gz ...
moving libflashplayer.so to /usr/lib/flashplugin-nonfree ...
setting permissions and ownership of /usr/lib/flashplugin-nonfree/libflashplayer.so ...

I assume all people not using the script but cp-ing the extracted content of the flash-tar.gz to the appropriate directory have this 501:501 ownership.
This assumption is wrong. at least here. I don't know how cp is supposed to work when copying files, preserve attributes of the old file for the new file? This is how it works here.

ReinerS, how did you update flash last time?

I think there is no need do file a bug report but we need to warn our users who update manually to change ownership of the extracted files to root:root before cp-ing them.

Waiting for someone or other to verify.

So still no real clue what exactly causes the change of ownership.


Edit:
It seems using mc (midnight commander) for copying those file causes the ownership to be changed to the one of the copied file. I in mc have set the option "preserve attributes" which to me isn't really unambiguous. Preserve whichone, the ones of the copied file or the existing.

I remember that I once used mc for updateing flash. And I think I checked the "preserve attributes" box.
Ok, you can't code, but you still might be able to write a bug report for Debian's sake

ReinerS

#16
I have here the 11.2.202.400 package.
As the script, to my knowledge/memory, at this time wasn't ready for that I have copied the content via mc.
So this probably might have caused the problem.

The script might have taken care of that.

regards


Reiner

Edit: Well just played around with it and unchecking "preserve attributes" does the trick.
slackware => SuSE => kanotix => sidux => aptosid  => siduction

michaa7

#17
Quote from: der_bud on 2014/08/20, 08:22:05
Quote from: michaa7 on 2014/08/19, 22:32:08Are you sure *all* directories and files in /usr belong to root?...

Here on 32bit all but /usr/local belong to root:root, while local and the dirs inside belong to root:staff (0 50).
...

... which unfortunatly isn't true:

#1
You won't be able to use mlocate as user until after you change owner and mod.
Note owner and SUID for group
Quote$ dir -l /usr/bin/mlocate
-rwxr-sr-x 1 root mlocate 35816 Jun 13  2013 /usr/bin/mlocate

#2
chromium won't start anymore. When starting in VT you'll see that the chromium sandbox needs file mode bits different from what they are after you issued "chown -R root:root /usr/"

I can't await for more to come ... :-(


BTW: I won't mind if a mod moved this thread away from "upgrade-warnings", because it isn't and wasn't. And, again btw, this section should be called "dist-upgrade-warnings", you know why.



Ok, you can't code, but you still might be able to write a bug report for Debian's sake