`/bin`, `/root`, ..., listed as owned by current user (`root` when `root`, `user` when `user`)

[personalizedrefrigerator]

Problem description

Many folders directly in / are writable by any user. I'm not sure if this is a proot issue or a proot-distro issue (or if this is really a feature request!).

Steps to reproduce

% ./ubuntu_login                                    # uses proot-distro login ubuntu
localhost# cd /
localhost# ls -l
total 89
drwxr-xr-x.  52 root root           1040 Feb 16 22:02 apex
lrwxrwxrwx.   1 root root             18 Nov 27 06:52 bin -> usr/bin
drwxr-xr-x.   2 root root           3488 Oct 11 01:39 boot
drwx------.   4 root root           3488 Dec 12 23:45 data
drwxr-xr-x.  23 root root           5140 Feb 25 15:38 dev
drwxr-xr-x. 163 root root          20480 Feb 25 15:55 etc
drwxr-xr-x.   3 root root           3488 Dec 10 15:28 home
lrwxrwxrwx.   1 root root             18 Nov 27 06:52 lib -> usr/lib
drwx------.   2 root root           3488 Dec 12 23:45 linkerconfig
drwxr-xr-x.   2 root root           3488 Nov 27 06:52 media
drwxr-xr-x.   2 root root           3488 Nov 27 06:52 mnt
drwxr-xr-x.   3 root root           3488 Dec 20 08:38 opt
dr-xr-xr-x. 675 root root              0 Dec 31  1969 proc
drwx------.   9 root root           3488 Feb  6 07:34 root
drwxr-xr-x.  17 root root           3488 Jan 31 12:33 run
lrwxrwxrwx.   1 root root             18 Nov 27 06:52 sbin -> usr/sbin
drwxrwx---.  20 root aid_everybody  3488 Feb 11 20:05 sdcard
drwxr-xr-x.   2 root root           3488 Nov 27 06:52 srv
drwx------.   2 root root           3488 Dec 12 23:45 storage
dr-xr-xr-x.  13 root root              0 Feb 16 22:02 sys                                                                           drwxr-xr-x.  21 root root           4096 Dec 31  2008 system
drwxrwxrwt. 103 root root          20480 Feb 25 16:05 tmp
drwxr-xr-x.  11 root root           3488 Nov 27 06:52 usr
drwxr-xr-x.  13 root root           3488 Jan 12 17:16 var
drwxr-xr-x.  13 root          2000  4096 Dec 31  2008 vendor
localhost# su mesozoic
$ ls -la
total 96
drwxr-xr-x.  24 mesozoic mesozoic       3488 Feb 25 15:54 .                                                                         drwxr-xr-x.  24 mesozoic mesozoic       3488 Feb 25 15:54 ..
drwxr-xr-x.  52 root     root           1040 Feb 16 22:02 apex
lrwxrwxrwx.   1 mesozoic mesozoic         18 Nov 27 06:52 bin -> usr/bin
drwxr-xr-x.   2 mesozoic mesozoic       3488 Oct 11 01:39 boot
drwx------.   4 mesozoic mesozoic       3488 Dec 12 23:45 data
drwxr-xr-x.  23 root     root           5140 Feb 25 15:38 dev
drwxr-xr-x. 163 mesozoic mesozoic      20480 Feb 25 15:55 etc
drwxr-xr-x.   3 mesozoic mesozoic       3488 Dec 10 15:28 home                                                                      lrwxrwxrwx.   1 mesozoic mesozoic         18 Nov 27 06:52 lib -> usr/lib
drwx------.   2 mesozoic mesozoic       3488 Dec 12 23:45 linkerconfig
drwxr-xr-x.   2 mesozoic mesozoic       3488 Nov 27 06:52 media
drwxr-xr-x.   2 mesozoic mesozoic       3488 Nov 27 06:52 mnt
drwxr-xr-x.   3 mesozoic mesozoic       3488 Dec 20 08:38 opt
dr-xr-xr-x. 676 root     root              0 Dec 31  1969 proc
drwx------.   9 mesozoic mesozoic       3488 Feb  6 07:34 root
drwxr-xr-x.  17 mesozoic mesozoic       3488 Jan 31 12:33 run
lrwxrwxrwx.   1 mesozoic mesozoic         18 Nov 27 06:52 sbin -> usr/sbin
drwxrwx---.  20 root     aid_everybody  3488 Feb 11 20:05 sdcard
drwxr-xr-x.   2 mesozoic mesozoic       3488 Nov 27 06:52 srv
d---------.   2 mesozoic mesozoic       3488 Dec 12 23:45 storage
dr-xr-xr-x.  13 root     root              0 Feb 16 22:02 sys
drwxr-xr-x.  21 root     root           4096 Dec 31  2008 system
drwxrwxrwt. 105 mesozoic mesozoic      20480 Feb 25 16:05 tmp
drwxr-xr-x.  11 mesozoic mesozoic       3488 Nov 27 06:52 usr
drwxr-xr-x.  13 mesozoic mesozoic       3488 Jan 12 17:16 var
drwxr-xr-x.  13 root              2000  4096 Dec 31  2008 vendor

Verbose output: log.txt

Expected behavior

• Regardless of the current user, folders like /root and /etc should always be listed as owned by root.
• An unprivlidged user should not be able to create new files in the root directory.

Additional information

Application version:
0.118.0
Packages CPU architecture:
aarch64
Subscribed repositories:
# sources.list
deb https://packages-cf.termux.org/apt/termux-main/ stable main
# game-repo (sources.list.d/game.list)
deb https://packages.termux.org/apt/termux-games games stable
# science-repo (sources.list.d/science.list)
deb https://packages.termux.org/apt/termux-science science stable
# x11-repo (sources.list.d/x11.list)
deb https://packages.termux.org/apt/termux-x11 x11 main
Updatable packages:
All packages up to date
Android version:
11
Kernel build information:
Linux localhost 4.14.113-22495969 #1 SMP PREEMPT Mon Dec 20 10:17:51 +07 2021 aarch64 Android
Device manufacturer:
samsung
Device model:
SM-P610

[ghost]

proot does not handle file ownership and it's incorrectly handled. intended behavior

You may want to check #140 for use of ownership in proot. while performance may or may not be noticable. there may be more issues with this feature

[personalizedrefrigerator]

proot does not handle file ownership and it's incorrectly handled. intended behavior

You may want to check #140 for use of ownership in proot. while performance may or may not be noticable. there may be more issues with this feature

Makes sense! Thank you!

[michalbednarski]

Also, I'll add that proot is not security sandbox, only compatibility one, so it cannot guarantee containment of programs executed inside it in either configuration

[SDRausty]

intended behavior

What are intended behaviors? be Can this intended behavior be elaborated upon please?

[michalbednarski]

intended behavior

Can this intended behavior be elaborated upon please?

As I've previously noted goal of proot is compatibility and unless some program someone wants to run in proot relies on being unable to write to these directories it is not considered a bug

The no-ownership-keeping behavior of proot was there already when I've took over it and I think it is good enough for compatibility needs and doesn't justify added complexity (although there is support for that in USERLAND builds, this isn't default, both because that isn't generally needed for compatibility as well as there was no clear migration path for adding such feature to already installed rootfs-s)

[SDRausty]

no-ownership-keeping behavior of proot was there already when I've took over it and I think it is good enough for compatibility needs and doesn't justify added complexity

I agree; For example DOS OS and later Windows32 justified not adding complexity. It worked!

not considered a bug

Neither was it considered a DOS bug. Thank you for replying. Who owns the proot files? I take it it it PRoot, unless we consider upstream.

linux group user ?

root when root, user when user

The logins vary? Who is radio? Who is system?

I would ask who root is, but I would like to know more about the fake permission hiearchy please?

[ghost]

I would ask who root is, but I would like to know more about the fake permission hiearchy please?

The metadata of ownership and permission file index is stored in hidden .proot-meta-file.file so once prooted guest system is initiated ownership and permissions will be applied from the metafiles

this would increase a very small amounts of space and a number of files (unless can be hidden with -H) and performance may decrease when writing file information before it's properties are changed and ownership is now being applied, whenever who logins as user they can't access or write somebody's files that isn't owned by theirs

---

This is the problem when updating proot with such support while somebody have guest system installed would crumple their installation for not having proper ownership

[SDRausty]

.proot-meta-file.file

Thank you for your answer @wmcbtech30; I managed to find issue, "enhance the link2symlink with a log file named $PROOT_L2S_LOG #186" issue which shares a little more information following up on your reply.

[SDRausty]

proot does not handle file ownership and it's incorrectly handled. intended behavior

Do I understand you correctly @wmcbtech30 ?

"PRoot does not handle file ownership, and this is intended behavior."

[SDRausty]

proot is not security sandbox, only compatibility one, so it cannot guarantee containment of programs executed inside it in either configuration

Thank you for replying; As far as I see, there is none. PATH sandboxes, but this is irrelevant. What about binds? Can someone explain the binds aspect a little more, and how binds is relevant to PATH please?

program needs path = it is sandboxed

program needn't path = it is sandboxed NOT

[personalizedrefrigerator]

It looks like this is breaking chrome and electron-based apps:

The SUID sandbox helper binary was found, but is not configured correctly. Rather than run without sandboxing I'm aborting now. You need to make sure that /home/mesozoic/Programming/joplin/packages/app-desktop/node_modules/electron/dist/chrome-sandbox is owned by root and has mode 4755.

I get a similar error when attempting to launch chromium (I'm running manjaro-aarch64 within proot-distro).

[ghost]

The current workaround is passing --no-sandbox flag to chromium and it's friends