[dmd]

What I really want is a way to get a read only root shell. I do a lot of work on a "traditional" multi-user unix host, where hundreds of scientists share a powerful computer. I often need to become root to look at files. I want to be able to do that without the ability to screw anything up.

[jcalvinowens]

If it's Linux, you can bind-mount the rootfs read-only and chroot into it:

    mahler ~ # mkdir /roroot
    mahler ~ # mount -o bind,ro / /roroot
    mahler ~ # chroot /roroot
    mahler / # passwd
    Enter new password: 
    Re-type new password: 
    passwd: Authentication token lock busy
    passwd: password unchanged

[dmd]

Oh, that's a good idea.

[jeroenhd]

I've used this command to achieve that in the past:

    sudo systemd-nspawn --directory=/ --read-only --ephemeral --volatile=yes

[systemd-nspawn](https://man7.org/linux/man-pages/man1/systemd-nspawn.1.html) would normally be used to run a command inside of a container (a directory), but in some modes you can specify the system root as the "container" path.

I believe this specific set of options relies on (BTRFS) file system snapshots for performance. It's possible that you can get it to work on non-BTRFS systems by providing another combination of command line variables, but the default setting is to copy the file system tree to a temporary path.

You can also pass parameters like --volatile=state (so you can write to /var) and --volatile=overlay (so you can "write" to state, but all changes are discarded after the container exits). --volatile=state is useful for extracting data from a temporary read-only system, --volatile=overlay is useful for running tools that crash if they run on a read-only filesystem.

[ronsor]

> I believe this specific set of options relies on (BTRFS) file system snapshots for performance. It's possible that you can get it to work on non-BTRFS systems by providing another combination of command line variables, but the default setting is to copy the file system tree to a temporary path.

You can use overlayfs + chroot.

[ape4]

--read-only would be a nice option for `run0`

[rkeene2]

I've used seccomp in the past to create a read-only root.

I created a seccomp DSL to make this kind of stuff easier [0] (an example of dropping network access is at [1])

[0] https://chiselapp.com/user/rkeene/repository/bash-drop-netwo...

[1] https://chiselapp.com/user/rkeene/repository/bash-drop-netwo...

[makemyworkforme]

Can you create a group and set a sticky bit for ACLs for your root for the filesystem with read permissions for that group? That way all files created under the filesystem root will have read permissions for that user, but you cannot modify anything.

[dmd]

Not really, there are tons of different filesystems mounted from all over the place. It's a mess.

[spease]

Can you create a second read-only mount of root?

Maybe this would help:

https://serverfault.com/questions/136515/read-only-bind-moun...

[dmd]

But the point is I want my 'root' session to have no ability to do anything destructive.

[dmd]

Though as someone just suggested in another thread, chrooting into such a thing isn't a terrible idea. It certainly limits the damage I can do.

[6r17]

MicroOS has something in that spirit I think ? Maybe I'm wrong tough, don't even know if MicroOS is usable in host