First off, I am using Bubblewrap as the sandboxing software, but I feel like it is a general mounting issue, than a bubblewrap one. I am trying to add bwrap into a sandbox wrapper called sandboxlib, the details are not important, other than the tests that are run.
One particular test tries to mount the sandbox / from "/foo/bar". This contains 2 sub-directories, data and bin.
The bin directory simply contains a simple binary called 'test-file-is-writable'.
If I run:
$ /usr/bin/bwrap --ro-bind /foo/bar / --tmpfs /data test-file-is-writable data/1/canary
Couldn't open data/1/canary for writing.
HOWEVER, mounting / as writable works
$ /usr/bin/bwrap --bind /foo/bar / --tmpfs /data test-file-is-writable data/1/canary
Wrote data to data/1/canary.
However, I am only wanting /data to be writable, and assuming the rest of / to be ro
Adding in a remount as readonly still doesn't fix things
$ /usr/bin/bwrap --ro-bind /foo/bar / --tmpfs /data --remount-ro / test-file-is-writable data/1/canary
Couldn't open data/1/canary for writing.
Debugging this further, I added in mounts/paths required to drop into an interactive shell inside the sandbox
$ /usr/bin/bwrap --bind /foo/bar / --tmpfs /data --ro-bind /lib /lib --ro-bind /lib64 /lib64 --ro-bind /bin /usr/bin --remount-ro / bash
Running a simple ls of / shows everything is mounted as expected. Testing r/w is all fine. The issue, however, is the /data directory is totally empty (other than the output of my 'touch /data/testwrite'). Note the original /data partition I wanted to mount, actually contains files.
Q. Am I not understanding the mounting here? Or are the tests wrong?
My only work around I can see is to copy over files from the original ro /data to the newly write-mounted /data
data/1/canary is a relative path and the current directory is not the root directory, so you are trying write to somewhere else
Related
I'm trying to make a fast reboot to the other Linux system. First step is kernel loading, I make it with
sudo kexec --append='$(cat /proc/cmdline)' -l new_kernel.img --reuse-cmdline
sudo kexec -e
It works fine, but loads only kernel, not entire system.
How can I mount an *.img file with OS resources, located at USB as /? Preferable during kernel loading, but afterwards mount is still suitable. *.img format is not necessary, it can be unpacked before
As stark said, pivot root() was the call I was searching for. Commands to make a USB located at /dev/sdb1 a root directory:
sudo -s
mkdir /newroot
mount /dev/sdb1 /newroot
cd /newroot
mkdir oldroot
pivot_root . oldroot/
switch_root() deletes all files at the previous root dir, also there are few other differences, this answer might be useful
this happens when I have
an executable that is in the /tmp directory (say /tmp/a.out)
it is run by a root shell
linux
selinux on (default for RedHat, CentOS, etc)
Apparently trying to run an executable that sits in the /tmp/directory as root revokes the privileges. Any idea how to go around this issue, other than turning off selinux? Thanks
You can set file context on binary or directory (containing binary) that are in /tmp that you want to run.
sudo semanage fcontext -a -t bin_t /tmp/location
Then restorecon:
sudo restorecon -vR /tmp/location
Just have a look at the mount options for /tmp directory, most probably you have no-exec option on it (there are many security reasons of doing that, the first being that anyone can put a file in the /tmp directory)
I'm running zsh on a Raspberry Pi 2 (Raspbian Jessie). zsh compinit is complaining about the /tmp directory being insecure. So, I checked the permissions on the directory:
$ compaudit
There are insecure directories:
/tmp
$ ls -ld /tmp
drwxrwxrwt 13 root root 16384 Apr 10 11:17 /tmp
Apparently anyone can do anything in the /tmp directory. Which makes sense, given it's purpose. So I tried the suggestions on this stackoverflow question. I also tried similar suggestions on other sites. Specifiacally, it suggests turning off group write permissions on that directory. Because of how the permissions looked according to ls -ld, I had to turn off the 'all' write permissions as well. So:
$ sudo su
% chmod g-w /tmp
% chmod a-w /tmp
% exit
$ compaudit
# nothing shows up, zsh is happy
This shut zsh up. However, other programs started to break. For example, gnome-terminal would crash whenever I typed the letter 'l'. Because of this, I had to turn the write permissions back on, and just run compinit -u in my .zshrc.
What I want to know: is there any better way to fix this? I'm not sure that it's a great idea to let compinit use an insecure directory. My dotfiles repo is hosted here, and the file where I now run compinit -u is here.
First, the original permissions on /tmp were correct. Make sure you've restored them correctly: ls -ld /tmp must start with drwxrwxrwt. You can use sudo chmod 1777 /tmp to set the correct permissions. /tmp is supposed to be writable by everyone, and any other permissions is highly likely to break stuff.
compaudit complains about directories in fpath, so one of the directories in your fpath is of the form /tmp/… (not necessarily /tmp itself). Check how fpath is being set. Normally the directories in fpath should be only subdirectories of the zsh installation directory, and places in your home directory. A subdirectory of /tmp wouldn't get in there without something unusual on your part.
If you can't find out where the stray directory is added to fpath, run zsh -x 2>zsh-x.log, and look for fpath in the trace file zsh-x.log.
It can be safe to use a directory under /tmp, but only if you created it securely. The permissions on /tmp allow anybody to create files, but users can only remove or rename their own files (that's what the t at the end of the permissions means). So if a directory is created safely (e.g. with mktemp -d), it's safe to use it in fpath. compaudit isn't sophisticated enough to recognize this case, and in any case it wouldn't have enough information since whether the directory is safe depends on how it was created.
Produces the following command on Ubuntu 64bit on VMWare:
mount /dev/sda1 /newroot
cd /newroot
mkdir old-root
pivot_root . old-root
I get an error that I do not understand
pivot_root: device or resource busy
Any ideas?
I saw the same error when the new root directory is a plain directory. When the new root is a mount, it will be ok. A bind mount of a directory is ok too. Also need to make sure the root directory permission is 0755, and owned by the root user.
The related answer states that you need to umount /proc first. I do not see the same.
The host ubnutu is 16.04 and it pivots into 18.04. Used unshare -m -p -f /bin/bash, followed by pivot_root . old_root. The -f is necessary to avoid a memory allocation error.
My app uses log4j and writes the logs to directory A which is in root directory. I want to move the logs out to a mounted drive without making any change in the application.
Can I use soft symlink to do this? I have created a symlink like this -
ln -s A mounted_drive_directory
But I still see logs written to directory A.
ln [OPTION]... [-T] TARGET LINK_NAME, so your arguments order is wrong. You'll have to delete (or move) A first before creating the link, or filename conflict will occur.
You could also use mountpoint bindings for that, e.g. mount --rbind /mounted/drive/directory /full/path/to/A, but it have to be done on each system boot (or saved in /etc/fstab to be auto-executed on boot).
ln works a little bit different:
first argument is real folder\file, second - symlink.
mv /root/A /root/B;
ln -s mounted_drive_directory /root/A;