一级做人爱c视正版免费

[Johannes Schauer]

Control: forcemerge 914915 -1

Hi Patrick,

Quoting Patrick Schleizer (2019-02-02 15:05:00)
> # How to reproduce:
> 
> sudo mmdebstrap --mode=root
> --aptopt=/home/user/whonix_binary/aptgetopt.conf stretch
> /var/cache/pbuilder/base.cow
> /home/user/whonix_dot/Whonix/build_sources/debian_stable_current_clearnet.list
> 
> (Could probably simplified but I hope you can reproduce this easily /
> hope you also have usr/bin/mkdir.)
> 
> # Expected result:
> 
> base.cow/bin/mkdir exists.
> 
> base.cow/usr/bin/mkdir does not exist
> 
> # Actual result:
> 
> base.cow/bin/mkdir exists.
> 
> base.cow/usr/bin/mkdir exists.
> 
> base.cow/usr/bin/mkdir matches base.cow/bin/mkdir.
> 
> diff base.cow/usr/bin/mkdir base.cow/bin/mkdir ; echo $?
> 0
> 
> Also many (if not all) other coreutils that should only reside in /bin
> such as /bin/rm are duplicated in /usr/bin such as /usr/bin/rm.
> 
> # Why this is a problem:
> 
> /usr/bin is preferred over /bin with default $PATH setting.
> 
> - When coreutils is later updated, it will only update /bin/mkdir and so
> forth but not /usr/bin/mkdir. This is because /bin/mkdir is owned by
> coreutils (dpkg -S /bin/mkdir) but /usr/bin/mkdir is owned by no package
> (dpkg -S /usr/bin/mkdir).
> 
> - This leads to apparmor issues. In apparmor profiles one has to
> hardcode for example /bin/mkdir but since /usr/bin/mkdir exists, this
> call will be denied.
> 
> # Misc:
> 
> I couldn't figure out from the source code why this is happening.
> Intended or unintended behavior? If intended, can this be turned off?
> Are also other files in unusual places?

the observations you describe are due to the following symlinks (using your
paths as examples):

base.cow/bin -> usr/bin
base.cow/sbin -> usr/sbin
base.cow/lib -> usr/lib

And depending on your architecture there are even a few more of those. So you
will see that the files base.cow/bin/mkdir and base.cow/usr/bin/mkdir are
actually the same files. You can use $(stat -c '%i') to compare the inode
numbers.

The idea behind creating these symlinks from foo to usr/foo is called "merged
/usr", "usr merge" or "usr move" and is a concept that has been introduced in
other distributions like Fedora:

https://fedoraproject.org/wiki/Features/UsrMove

And also Debian is doing experiments with it:

https://wiki.debian.org/UsrMerge

For a while, the tool debootstrap which is doing something very similar to
mmdebstrap was creating "merged /usr" systems that include these symlinks by
default. It then turned out that it was a bad idea to have this default before
other problems aren't solved yet and thus the default was changed back to the
old behaviour. Unfortunately, I wrote mmdebstrap in the timeframe when
debootstrap still defaulted to the "merged /usr" behaviour and since I just
wanted to provide the same feature as debootstrap, this became the default of
mmdebstrap as well.

Due to the discovered problems, "merged /usr" should *not* be the default for
mmdebstrap for now and that's why this bug was reported already:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914915

As a result, "merged /usr" has been disabled in mmdebstrap since this commit:

https://gitlab.mister-muffin.de/josch/mmdebstrap/commit/97d273aaf6ada19f4966666ba75d907ee64b0a75

So the only thing that is needed, is for a new mmdebstrap release and then this
bug will be fixed. :)

Thanks!

cheers, josch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: signature
URL: <http://www.whonix.org/pipermail/whonix-devel/attachments/20190202/49825cb6/attachment.sig>