[SOLVED] LXDE update postinst chown'ing my whole home dir

Started by LeYaude, 2013/07/03, 15:16:31

Previous topic - Next topic

LeYaude

Hello,

I have run into something a bit weird I think. I don't know if it's really a bug or is normal.
During my last update (currently suspended), I have noticed that "siduction-settings-lxde postinst" has launched a (my username being 'leyaude') :
chown -R leyaude:leyaude /home/leyaude

Why in the world would it do that ? Apart from the fact that it will take hours, I may not be very happy with the result. Should I report this as a bug ? Or do you think I could have some compromised software triggering this behaviour ? I think this is unlikely as I had no key problem, the package seems to come from ftp.spline.de.

Any insight would be greatly apreciated, thanks,
Yoann.

michaa7

Apart from it being forced, the result should look like *every* home which is owned by <user>:<user>.
Ok, you can't code, but you still might be able to write a bug report for Debian's sake

LeYaude

Thanks for the answer. My reserves are with the recursive part. What if I had a folder like
-rw-r---- <user> myfriends Public/
where I could put stuff for my friends to see ? I thinks that's a reasonable situation (please tell me if I'm wrong) that would be (silently) ruined by the update. That's why I'm not fond of the update touching recursively my whole home directory.

michaa7

Quote from: "LeYaude"... My reserves are with the recursive part. What if I had a folder like
-rw-r---- <user> myfriends Public/
where I could put stuff for my friends to see ? I thinks that's a reasonable situation (please tell me if I'm wrong) that would be (silently) ruined by the update.

You are right. That was the part which I silently skiped. I could guess that this situation exists on your computer, but I never would mix ownership within my home. I'd rather created a special partiton with different group permissions which I then link into my home (note: the chown -R option does *not* follow symlinks by default). So no *technical* problem for me.

QuoteThat's why I'm not fond of the update touching recursively my whole home directory.
I can understand this perfectly. I wouldn't appreciate it at all if someone else fumbled around in what I have configured thoroughfully.

Historically there was a difference between sidux (predecessor of aptosid->siduction) and Debian regarding the default policy for user's home. Debian set the permission to readable for all, sidux didn't. But if I recall correctly the Debian policy was changend, not sure.
Maybe there still exist some permission conflicts between siduction and Debian which results in this command in a siduction script.
Ok, you can't code, but you still might be able to write a bug report for Debian's sake

LeYaude

Ok, I'll remember the advice for the separate partition, I'm far from a seasoned admin, so I always take them gladly :-). And thank you for the historical part, I ignored that too !

I'll set the thread as resolved then, as I don't think this behaviour can really be called a bug.

Thanks.

EDIT : I let the script do its chown, but it failed on .gvfs (something to do that fuse volumes are not touchable by someone else that the user that mounted the volume, I think).
In case anyone hits it too, to work around it, unmounting .gvfs, then do the update seems to work.

michaa7

Quote from: LeYaude... I'm far from a seasoned admin,
so am I. But that's the fun with open source operating systems: No secrets, you always can understand a piece of the puzzle.


Quote
EDIT : I let the script do its chown, but it failed on .gvfs (something to do that fuse volumes are not touchable by someone else that the user that mounted the volume, I think).
In case anyone hits it too, to work around it, unmounting .gvfs, then do the update seems to work.

To me it seems that this is the same bug as mentioned here:
http://forum.siduction.org/index.php?msg=30725#30725

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

LeYaude

Quote from: michaa7

Quote
EDIT : I let the script do its chown, but it failed on .gvfs (something to do that fuse volumes are not touchable by someone else that the user that mounted the volume, I think).
In case anyone hits it too, to work around it, unmounting .gvfs, then do the update seems to work.

To me it seems that this is the same bug as mentioned here:
http://forum.siduction.org/index.php?msg=30725#30725

Maybe worth to chime in.

Thanks for pointing this out, I've put my two cents on the thread.