Current limitations (Fedora 21 for AArch64, yum: Permission denied)?

[David Abdurachmanov]

// Hopefully not a double post, otherwise apologies in advance

Hi,

I learned about PRoot at FOSDEM and wanted to use it for a long time. Currently
I am using chroot, binfmt_misc, QEMU 2.2.0 (user mode) and Fedora 21 for
AArch64 rootfs. This allows me to build AArch64 RPMs without having a farm of
AArch64 machinery. I wanted to provide easy setup instructions for users to try
out/fix AArch64 software. PRoot came to my mind as it's a single static binary
and does not require root permissions. Simply put perfect.

My host is x86_64, Scientific Linux 6.6 (basically RHEL). QEMU 2.2.0
(statically built). PRoot nightly build (Jan 4th,
http://static.proot.me/proot-x86_64). Fedora 21 rootfs from
F21-20141216-server-RC7.

PRoot launch command: ./proot-x86_64 -S /data/davidlt/quemu22/rootfs/ -q
"/data/davidlt/quemu22/qemu-2.2.0/aarch64-linux-user/qemu-aarch64"

There are two things I noticed:

(1) Invisible mount though I am not using PROOT_DONT_POLLUTE_ROOTFS.
/host-rootfs and /data (external HDD) is available on quest rootfs, but
invisible. Is this expected without PROOT_DONT_POLLUTE_ROOTFS? Also does PRoot
makes NFS, AFS and custom networked file systems available on quest rootfs
automatically?

-sh-4.3# stat /data
File: ‘/data’
Size: 4096 Blocks: 8 IO Block: 4096 directory
Device: 811h/2065d Inode: 9969781 Links: 4
Access: (0700/drwx------) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2015-01-04 05:36:27.000000000 -0500
Modify: 2015-01-04 05:32:38.000000000 -0500
Change: 2015-01-04 05:32:38.000000000 -0500
Birth: -
-sh-4.3# stat /host-rootfs
File: ‘/host-rootfs’
Size: 4096 Blocks: 8 IO Block: 4096 directory
Device: 811h/2065d Inode: 2 Links: 29
Access: (0555/dr-xr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2015-01-04 02:30:22.000000000 -0500
Modify: 2014-11-27 10:50:42.000000000 -0500
Change: 2014-11-27 10:50:42.000000000 -0500
Birth: -
-sh-4.3# ls /
bin boot dev etc home lib lib64 media mnt opt proc root run sbin srv sys tmp usr var

(2) Seems that root permissions aren't enough. I was not able to use yum to
update or install packages with PRoot. I couldn't create file or directory in
/var/run (symlink to ../run), which is fully in guest rootfs. Same with some
executables like `sudo'.

-sh-4.3# sudo
-sh: /bin/sudo: Permission denied
-sh-4.3# yum makecache
Loaded plugins: langpacks
Cannot open logfile /var/log/yum.log
Could not create lock at /var/run/yum.pid: [Errno 13] Permission denied: '/var/run/yum.pid'


Can't create lock file; exiting
-sh-4.3# id
uid=0(root) gid=0(root) groups=0(root),1399,1098336343
-sh-4.3# whoami
root

-sh-4.3# cd /var/run
-sh-4.3# pwd
/var/run
-sh-4.3# ls -la
total 8
drwxr-xr-x. 2 root root 4096 Dec 16 16:56 .
dr-xr-xr-x. 17 root root 4096 Dec 16 17:18 ..
-sh-4.3# mkdir a
mkdir: cannot create directory ‘a’: Permission denied
-sh-4.3# touch a
touch: cannot touch ‘a’: Permission denied

Is this expected?

Thanks,
david

[ced...@reproducible.io]

Hello David,

I shuffled your mail a bit to make my answers simpler. Sorry in
advance if this makes you confused.

> (1) Invisible mount though I am not using PROOT_DONT_POLLUTE_ROOTFS.
> /host-rootfs and /data (external HDD) is available on quest rootfs,
> but invisible. Is this expected without PROOT_DONT_POLLUTE_ROOTFS?

[...]

> (2) Seems that root permissions aren't enough. I was not able to use
> yum to update or install packages with PRoot. I couldn't create file
> or directory in /var/run (symlink to ../run), which is fully in
> guest rootfs. Same with some executables like `sudo'.

As of my understanding, you are using PRoot as a regular user with a
guest rootfs owned by someone else (by root I suppose, since you used
to chroot into it). This explains why you don't have write permission
in this guest rootfs; that's required by yum (in your example), and by
PRoot to make its mount points visible (this requirement will be
likely removed in PRoot v6).

You just have to use a guest rootfs you own, either by running "chown
-R" against it (once), or by running proot as root (strongly *not*
recommended!). For example, I always use PRoot as a regular user with
a guest rootfs I extracted or copied as a regular user. That way, no
privileges are ever required.

Regarding the "-S" or "-0" options, they are required to run programs
that assume they are executed with all permissions. For exemple, Yum
(indirectly) assumes it can create files in directories where write
permission is removed:

- as a regular user:

$ mkdir foo
$ chmod a-w foo
$ touch foo/bar
touch: cannot touch ‘foo/bar’: Permission denied

- as root:

# mkdir foo
# chmod a-w foo
# touch foo/bar
# file foo/bar
foo/bar: empty

- as a regular user using proot "-0" or "-S":

$ proot -0
# mkdir foo
# chmod a-w foo
# touch foo/bar
# file foo/bar
foo/bar: empty
# exit
$ ls -l foo/bar
-rw-r--r-- 1 cedric users 0 Jan 6 11:12 foo/bar
$ ls -ld foo/
dr-xr-xr-x 2 cedric users 4096 Jan 6 11:12 foo/

In this last case, PRoot has faked the root id (ie. "0") and some of
its capabilities (eg. see CAP_DAC_OVERRIDE in the "man capabilities").

> Same with some executables like `sudo'.
>
> -sh-4.3# sudo
> -sh: /bin/sudo: Permission denied

It is worth saying that PRoot can't gain privileges (unless it is run
as root, which is strongly *not* recommended!). As a consequence it
is not possible to execute setuid binaries like "sudo" or "ping" under
PRoot. Most of the time "-0" or "-S" option is enough to emulate
"sudo" usage, assuming you have write permission in the guest rootfs.
For "ping" usage, I use "resolveip" and "netcat" instead.

> Also does PRoot makes NFS, AFS and custom networked file systems
> available on quest rootfs automatically?

PRoot doesn't care about the underlying file-system(s). Did you
notice something unexpected in this regard?


Please, let me know if you have other questions or comments.

Regards,
Cédric.