Remove root from build process

[deisi]

With fuse-ext2 it is possible to mount and manipulate the firmware image as
user. I further added a sync call before unmounting as this flushes the cache of
the firmware image.

For me this change was necessary as I use Arch Linux with btrfs filesystem and I couldn't mount the ext4 filesystem otherwise.

Disclaimer
I have not tested the firmware that resulted from this, as I don't want to brick my vacuum and my knowledge of recovering is limited. If somebody with more knowledge about this gives me a go and possibly some help in case of failure, I would of course test this.
Further I don't know what consequences these changes have on Mac OSX.

[deisi]

Okay, I was brave and just flashed it. As far as I can see everything works fine.

[fvollmer]

Great!
I think this is a good idea. The files created by the old files were always owned by root, which sometimes caused issues (e.g. you had to use sudo to rm them).

[deisi]

yes that is true, I also discovered a strange thing. Valetudo is working, but I cant ssh on the machine as of right now. I'm not sure what is causing it tough, as the public ssh key is part of the image.

[deisi]

Okay, now I'm sure this definitely adds a bug where one cant ssh on the machine any more. Now lets find out why the ssh key is not accepted when the firmware is build as user.

[slaecker]

Maybe wrong ownership of.ssh folder or authorized_keys file?

• ~/.ssh must be 700
  • authorized_keys must be 600

Just a blind guess.

[dgiese]

Yeah, the authorized_keys file must be owned by root...which can be an issue if you are not root while you create the image...

[deisi]

how about I add a script that changes owner ship of authorized_keys upon booting of the vacuum. This way the amount of root executed code would at least shrink down to a bare minimum. Or is the filesystem read only?

[fvollmer]

I have no experience with ext2-fuse, but what happens if you just add chown root:root $IMG_DIR/root/.ssh and chown root:root $IMG_DIR/root/.ssh/authorized_keys to the build script?

[deisi]

doesn't work. you need root to do so.

[fvollmer]

Are you sure? I just tried it myself and it appears to work.

[deisi]

where is the difference?

My fuse-ext2 version is:
fuse-ext2 0.0.9 29
can it be that? Or did you use another mounting option?

[fvollmer]

This is surprising to me. The only difference I can spot is the slightly different mount command, but this isn't explaining the Operation not permitted error. Does dmesg show any errors? What OS are you using (I just fired up an debian testing vm)?

[deisi]

dmesg looks fine. I'm on Arch Linux. Maybe something about the user groups:

[malte@mtop image]$ groups 
sys lock bumblebee network power gdm wireshark users video uucp storage lp input audio wheel malte snapper

In dmesg I only find:

[Mon May 6 02:32:21 2019] EXT4-fs (loop0): mounted filesystem with ordered data mode. Opts: (null)

but this looks very normal to me

[fvollmer]

fvollmer@debian-fvollmer:~$ groups
fvollmer cdrom floppy sudo audio dip video plugdev netdev lpadmin scanner vboxsf

[deisi]

I have no clue what so ever o.O

[fvollmer]

This sounds like the option default_permissions is active. (type mount)

/home/fvollmer/disk.img on /home/fvollmer/img type fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)

On further investigation it looks like this is the "new" default option:
https://github.com/alperakcan/fuse-ext2/blob/677722d2ff6e2019d523682f86162f7a5ef200f8/fuse-ext2/fuse-ext2.c#L29
In debian this option is not enabled.

It appears to me like you can't disable default_permissions. This would be an unintended consequence of alperakcan/fuse-ext2@0528a7c. I opened an issue alperakcan/fuse-ext2#95

[deisi]

I think you found the reason:

/home/malte/Projects/rockrobo/image/fw.pTK2yP/fw/disk.img on /home/malte/Projects/rockrobo/image/fw.pTK2yP/image type fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000,default_permissions,allow_other)

So if there is no way to turn off default_permission this won't work.

[fvollmer]

I used Arch Linux in a VM and patched fuse-ext2 to disable default_permissions. After this quick hack it just works fine:

I guess the best way would be to fix fuse-ext2 upstream. I won't have the time to do this.

[fvollmer]

I'm not sure if we should worry, but there is this big warning in the README.md

Even though write support is available, please do not mount your filesystems with write support unless you have nothing to lose.

[dgiese]

After reading the comments, I do not really feel comfortable to change the building system. While it is not nice to do it with root permissions, we at least know that it somehow works reliable. Not having ext4/ext3/ext2 support compiled in the kernel seems for me to be an edge case (correct me if I am wrong)...

[cryptomilk]

I agree with @dgiese :-)

[deisi]

Okay, Then I close this. Maybe at some point we have a better way.