feat: Improve support for unprivileged hosts (including LXC)

[databreach]

• Add fakeroot to extract the dsm system without elevated permissions
• Remove obsolete docker variable "DEV" used to exclude extraction of device nodes

[kroese]

Thanks!! I have no experience with fakeroot, but I am a bit in doubt if this works as intended.

When I read this for example: http://www.embeddedlinux.org.cn/OEManual/fakeroot.html it seems like fakeroot creates the device nodes as empty dummy files, that only appear as the correct devices while inside the fakeroot session, but not outside.

So that means that any code that follows to process the untarred files, will also need fakeroot otherwise it will just copy empty files to the DSM partition instead of real device nodes.

So for example this line:

mke2fs -q -t ext4 -b 4096 -d "$MOUNT/" -L "$LABEL" -F -E "offset=$OFFSET" "$SYSTEM" "$NUMBLOCKS"

copies all the extracted files to the DSM partition, but as its not running inside fakeroot, I do not think it will process the device nodes correctly.

So the most logical fix would be to also add the fakeroot command in front of mke2fs. But even this will not work because the page above mentions:

All information regarding devices nodes, uid and gids will be lost when fakeroot exits

So because we run fakeroot a second time, it will have forgotten the mapping between the empty dummy file and the device node that it had in memory during the first run.

So the only way to make it work correctly is to run the whole execution of install.sh inside fakeroot, but that may cause many unwanted side-effects in other sections of the code.

So I do not think this patch improves the current situation for unprivileged containers. As instead of skipping the files, you now just copy empty files, but its better to skip them so DSM may create the correct ones when it notices that they are missing.

[databreach]

Thank you for your feedback. I had considered using fakeroot for a bigger portion of install.sh, but I haven't experienced any issues using it as proposed. When you have time, please run the code and see if it returns any errors or if any of the required device nodes are missing.

[kroese]

I do not think this code will create any errors, and it will also not be missing files. But I think when I go inside DSM after installation, and look at /dev/net/tun it will just be an empty file.

I have not tested that yet, but if I read the fakeroot manual I am pretty sure that will be the case.

[databreach]

To the best of my knowledge of fakeroot (which is limited), the behavior of fakeroot depends on whether it is being used by a non-privileged user or by the actual root user. When a non-privileged user runs commands with fakeroot, the tool simulates root privileges by intercepting and faking certain system calls. If the root user is using fakeroot, the tool is effectively bypassed. The real root account already has true superuser privileges, so fakeroot doesn't need to simulate anything. As such, I don't believe its usage will be an issue.

[kroese]

@databreach That is not what I ment. I ment that for non-privileged users the device file would be invalid (empty). The reason is that fakeroot was only used during tar extraction. So the mke2fs command which comes next, will not see fake device nodes but the empty dummy files that fakeroot created. This is described in the article that I linked.

The solution is to run both tar and mke2fs inside the same fakeroot session, so that they both view the files in the same way.

I solved this now in the last commit, by starting a new bash shell in which both commands are executed before fakeroot exits:

fakeroot -- bash -c "set -Eeu;\
        tar xpfJ $HDA.txz --absolute-names --skip-old-files -C $MOUNT/;\
        mke2fs -q -t ext4 -b 4096 -d $MOUNT/ -L $LABEL -F -E offset=$OFFSET $SYSTEM $NUMBLOCKS"

[databreach]

Providing clarification is appreciated, and I apologize for any misunderstanding. The aim was to streamline the usage of virtual-dsm regardless of the user's privileges, and removing the necessity for the DEV variable is a positive refinement. I'm pleased to note that an enhanced version has been implemented. Thank you for the outstanding work you've done!