For those who aren't familiar, QEMU actually provides two completely
different sets of emulators
- system emulators - they emulate a full virtual machine and thus run
a full guest OS.
- user emulators - they emulate the Linux userspace ABI letting you
run non-native arch executables directly.
The user emulators are what I'm concerned with in this mail, so ignore
the system emulators.
Currently all the user emulators are provided in the "qemu-user" RPM
which also includes files in /usr/lib/binfmt.d to register each emulator
binary as a binary format handler for its respective architecture.
This is ok if you have a non-native arch binary that's statically linked
and you just want to run it from context of your main OS root filesystem.
Running dynamic linked binaries won't fly because if say running an arm
binary on x86_64 host, it'll look for /lib/libc.so and find the i386 one,
instead of the arm one. You can't set LD_LIBRARY_PATH to override this
as the env var will apply to both qemu-arm (an x86_64 binary) and the
binary it is trying to run (an arm binary).
More typical though is that you have a directory containing an fullish
install tree of a non-native architecture and you just want to chroot
into that. When doing such a chroot, the qemu-$ARCH emulator must be
present inside the chroot too. ie the x86_64 build of /usr/bin/qemu-arm
must be present inside at /my/chroot/for/fedora-arm/usr/bin/qemu-arm.
So again you have the potential problem of clashing libc.so in /usr/lib
It is a shame Fedora doesn't have full multi-arch support, instead of
merely multi-lib to avoid these clashing lib dirs across architecture
The recommended way to deal with this for the qemu user emulator binaries
to be statically linked, so when copied inside the non-native arch chroot,
they never need to resolve any native arch libraries. Fedora's qemu user
binaries are all dynamic linked right now.
Debian handles this by having several packages 
- qemu-user - the dynamic linked qemu user binaries
- qemu-binfmt - binfmt rules registering the dynamic linked binaries
- qemu-user-static - the static linked qemu user binaries *and* binfmt
rules to register them. The static binaries all
have -static suffix on their name
NB, this means qemu-binfmt and qemu-user-static are mutually exclusive
since they both provide the same binfmt files. You can however have both
qemu-user and qemu-user-static installed as their binary names won't
clash, and in this case the static ones will be registered as binfmts
This nice thing about this multiple package approach is that when you
copied the x86_64 build of the "qemu-arm-static" binary into your arm
chroot, you still then have the possibility of installing the arm build
of the "qemu-arm" binary inside that chroot without filename clash.
An alternative simpler approach would be to just have one package,
qemu-user, which contains the static binaries and never ship any
dynamic linked qemu user binaries. This is slightly more restrictive
though, as explained in the previous paragraph, so I'd like to avoid
I'd like to make using non-native arch chroots simple with Fedora without
people needing to manually build their own static QEMU binaries, or download
static binaries provided by another distro. So I'm suggesting to make a
change to Fedora qemu packages to essentially copy the way Debian has done
things. Specifically I will
- Pull the binfmt registration files out of qemu-user and into a
new qemu-binfmt package which depends on qemu-user.
- Add static builds of qemu user emulators to a new qemu-user-static
package, along with binfmt registration files
The static build of QEMU user emulators is moderately light on
dependancies, only requiring glib2-static, pcre-static, zlib-static
and glibc-static packages.
The change to introduce a qemu-binfmt package has small upgrade
implications since anyone with qemu-user installed today, will loose
the binary format rules unless they manually install qemu-binfmt. I
think the number of people affected is probably quite small, and some
of them may well wish to use qemu-user-static instead anyway.
Obviously this would only be done in rawhide, not any existing stable
releases of Fedora.
Nothing will change about the rest of QEMU packaging - ie all system
emulators will continue to use dynamic linking
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
While checking out the SPEC file of python, it seems there were some packages that, while separate at some point, they got included in python's stdlib and then obsoleted as standalone packages (thus to cope with the change, python was obsoleting these packages and providing them as well in the SPEC). So every package that currently (Build)Requires any of these packages will essentially drag python with it.
I will remove these provides soon, since the packages were orphaned long time ago, but the packages that still require them, will need to be fixed and (Build)Require python instead.
Here is a github commit with these changes from a testing repo:
And a list of the provided packages and the affected ones
Depending on feedback here I will follow (or not) the mass bug filling procedure so maintainer fix their packages.
The reasoning behind this change, at the current time, is that I intent to rename python to python2 soon, which will lead to a re-review of python, so at the moment trying to have things as clear and consistent as possible. Plans for that change is only for rawhide (although it would be nice for f25 as well).
Associate Software Engineer
Python Maintenance Team, Red Hat
I messed up the change proposal for Boost 1.61 in F25, which means it
isn't on the schedule.
Given the huge amount of work involved in every Boost update, I'm not
going to be too upset if I don't have to do it!
How upset will other people be if F25 ships with Boost 1.60 (same as
in F24)? Then F26 would get an update, possibly skipping 1.61 and going
straight to 1.62 which should be out by then.
Boost 1.61 adds four new libraries: Boost.Compute, Boost.DLL,
Boost.Hana and Boost.Metaparse.
Full 1.61 release notes:
On Wednesday, September 21, 2016 12:16:39 PM CEST buildsys(a)fedoraproject.org wrote:
> vim-syntastic has broken dependencies in the rawhide tree:
> On aarch64:
> vim-syntastic-lisp-3.7.0-6.fc26.noarch requires clisp
> On aarch64:
> vim-syntastic-cs-3.7.0-6.fc26.noarch requires mono-core
> On aarch64:
> vim-syntastic-d-3.7.0-6.fc26.noarch requires ldc
> On armhfp:
> vim-syntastic-d-3.7.0-6.fc26.noarch requires ldc
> Please resolve this as soon as possible.
What's should packager do in such case? Recap: noarch package depends on
arch-dependant package, which is not available everywhere.
I've just pushed (but not built) python-matplotlib-2.0.0b4 to rawhide.
I'll be attempting to rebuild all the affected packages locally to
test if they're compatible. In the meantime, feel free to git pull
and build locally for your own testing.
$ dnf repoquery --srpm --releasever=rawhide --whatrequires python-matplotlib --alldeps
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
nologin is listed in /etc/shells since 2002 .
This is in conflict with:
man 5 shells
/etc/shells is a text file which contains the full pathnames of
man 8 nologin
nologin displays a message that an account is not available and
non-zero. It is intended as a replacement shell field to deny
access to an account.
nologin is a per-account way to disable login (usually used for
accounts like http or ftp).
man 1 su
Run the specified shell instead of the default.
If the target user has a restricted shell (i.e. not listed
/etc/shells), the --shell option and the SHELL environment
ables are ignored unless the calling user is root.
Actual behavior and man pages are consistent for su and nologin and their
behavior is affected indirectly by /etc/shells. The inconsistency lies in
/etc/shells containing nologin and man 5 shells semantically telling the
Let's fix it.
The stated reason for including nologin in shells is "so that 'chsh' and
other tools will allow its use without manual edit of /etc/passwd" .
This is argument is inaccurate. Tests on RHEL 6.0 and fc24 showed that the
man page for chsh is correct - when /sbin/nologin is not in /etc/shells,
root can successfully run chsh -s /sbin/nologin username. It prints a
warning but it does change the default shell to /sbin/nologin. man 1 chsh:
chsh will accept the full pathname of any executable file on the
tem. However, it will issue a warning if the shell is not listed
the /etc/shells file. On the other hand, it can also be
such that it will only accept shells listed in this file, unless
Removing /sbin/nologin from /etc/shells would prohibit a regular user to
set /sbin/nologin as the default shell for themselves - an action that
makes little sense.
/sbin/nologin being in /etc/shells poses security and logical problems:
- su -s /bin/bash - nologinuser (if "nologinuser" has /sbin/nologin as the
default shell) succeeds with /bin/bash if auth is successful , even
though man 1 su, man 8 nologin, and man 5 shells suggest that such a user
is a restricted user and logging in with an alternate specified shell
should be forbidden.
- Red Hat Enterprise Linux 7 Security Guide advises  that /sbin/nologin
should be used to prevent direct login to an account - the root account in
this example. Presumably, this should be prevented in the case where the
attacker has valid login credentials for the account. In that very case,
however, the attacker can use an ordinary account to run su -s /bin/bash -
root because the protection for this very attack present in su is rendered
useless by /sbin/nologin being listed in /etc/shells.
- selinux has a workaround for /sbin/nologin -
- gdm has a workaround for /sbin/nologin -
- Debian doesn't list nologin in /etc/shells. An opinion from a Debian
developer : "The point of having a shell that's not in /etc/shells isn't
that you can't use it to log in, but that it's not a normal shell and that
users with that shell set can't change it to something else. Adding nologin
to /etc/shells would be very likely to open security vulnerabilities, and I
will not do it."
It seems as though /sbin/nologin is listed in /etc/shells as a workaround
to some issues without even documenting it in the man pages. These issues
are not important enough for those distributions and OSes that don't list
/sbin/nologin in /etc/shells. Maybe fedora should be on the same boat.
The rabbit hole of the past bugs and discussions about this starts here .
This is a bug that either lies solely in the setup package (which lists
/sbin/nologin in the /etc/shells file) or it is an inter-package bug where
multiple packages that are correct on their own exhibit an incorrect
behavior together. In any case, it is clear *something* is wrong here.
What can we do to fix this issue or to at least to make man pages
consistent with the actual behavior? Are there serious reasons to continue
listing /sbin/nologin in /etc/shells?
Jakub Svoboda / Red Hat Product Security