xbianonpi / xbian

XBMC on Raspberry Pi, Bleeding Edge
https://xbian.org
GNU General Public License v3.0
294 stars 46 forks source link

Critical permission problem, bad chown in maraschino script #845

Open danielmotaleite opened 6 years ago

danielmotaleite commented 6 years ago

I have been running the latest xbian and after weeks, after installing more software, my setup stop working, kodi would not start and i'm in the login prompt.

After some checks, i found that all the RPi2 is now own by root and all SUID programs lost their special bit... it looked like something made a chown -R root /

I reset the permissions the best i could ( chmod +s /usr/bin/sudo /bin/su ; chown -R xbian /home/xbian /home/xbian/.kodi/userdata/addon_data/plugin.xbianconfig ) and tried to find the origin of the problem... one day later, the same problem, so i changed the chown with a script to find what app was doing this.

And after a new boot, i found that the /etc/rc2.d/S03maraschino is doing a chown -R root /tmp as the /tmp have the btrfs volumes, including the current one, it is reseting the ownership of all the machine.

The maraschino package i have installed is : pool/stable/main/x/xbian-package-maraschino/xbian-package-maraschino_1.0_armhf.deb

So looking around i see 2 problems:

So please quickly fix the maraschino package to set a proper /etc/default/maraschino, so other setups where maraschino is installed aren't destroyed on the next boot

mkreisl commented 6 years ago

@danielmotaleite I was installing xbian-package-maraschino on my test rpi2, and everything works ok. No SUID bits were lost and after a reboot Kodi comes up as usual.

So it must be a special issue on your machine.

danielmotaleite commented 6 years ago

what do you have in /etc/default/maraschino , in the PID file?

i had /tmp/maraschino.pid ... maybe one setting from a older versions, i didn't updated my xbian for almost one year

If the current default is correct, then maybe moving the btrfs subvolumes out of /tmp is the only needed fix... as the tmp looks like a dangerous place to place the machine volumes, just in case another tool makes the wrong command. /media/btrfs looks lot better for me

mkreisl commented 6 years ago

what do you have in /etc/default/maraschino , in the PID file?

i had /tmp/maraschino.pid ... maybe one setting from a older versions, i didn't updated my xbian for almost one year

I haven't changed anything from default installation, so PID points to /tmp folder

There are no subvolumes mounted under /tmp, /tmp is part of root subvolume

danielmotaleite commented 6 years ago

ok, so your setup is also doing a chown -R root /tmp in the maraschino init script ... and that may not always the the best thing to do, as other apps may already exist there with different permissions, so i think that using /tmp/maraschino.pid as the pid is a bad idea, use a subfolder, or use the default /run/maraschino/marachino.pid as a safer setup

as the btrfs, i have in /tmp/tmp.??????/@* folders that are the btrfs sub-volumes... i will try to find where they are coming from, but i do not recall setting up anything to mount those sub-volumes on boot

mkreisl commented 6 years ago

ok, so your setup is also doing a chown -R root /tmp in the maraschino init script ... and that may not always the the best thing to do, as other apps may already exist there with different permissions, so i think that using /tmp/maraschino.pid as the pid is a bad idea, use a subfolder, or use the default /run/maraschino/marachino.pid as a safer setup

Agree, this is really not a good idea, IMO the init script isn't the best choice. It seems to be a 1:1 copy of the original script https://github.com/mrkipling/maraschino/blob/master/initd, and for my understanding

handle_pid () {
    PID_PATH=`dirname $PID_FILE`
    [ -d $PID_PATH ] || mkdir -p $PID_PATH && chown -R $RUN_AS $PID_PATH > /dev/null || {
        log_warning_msg "$DESC: Could not create $PID_FILE, aborting.";
        return 1;}
}

is wrong, because chown -R ... is executing always and not only if new PID_PATH has been created

as the btrfs, i have in /tmp/tmp.??????/@* folders that are the btrfs sub-volumes... i will try to find where they are coming from, but i do not recall setting up anything to mount those sub-volumes on boot

Ahhh, now we're coming closer to the problem. Yeah, that mount remains sometimes after boot. I wasn't successful in my investigation where this came from. Same happens here, but never if initramfs is not used. So it must be inside of initramfs scripts, but could not find anything there. If you could figure this out, it would be very helpful for me (initramfs scripts can be found there https://github.com/xbianonpi/xbian-package-initramfs/tree/master/content/etc/xbian-initramfs)