Need advice on NET_ADMIN capability on a binary (iotop-c)
by Boian Bonev
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hello,
I have got a pull request [1] that implements installing iotop-c with the
NET_ADMIN capability by default and I am trying to evaluate if that is OK or
not.
Currently iotop-c will only allow to be run as root. In case it is run as some
other user, it will advise to use sudo, or alternatively add the NET_ADMIN
capability to the binary:
sudo setcap 'cap_net_admin+eip' <path-to>/iotop
Obviously that will have to be redone after each update, adding some
inconvenience for admins who decide to allow that for non-root users. I have
never considered installing it suid - that would be an overkill and may
introduce security problems. I always use it as root and have never given that
too much thought, also never before did deep analyses of the consequences of
the above setcap.
Here is a brief list of the consequences of allowing non-root users to run it
by the setcap:
- - Process IO usage will be exposed [maybe OK]
- - Process list and command lines will be exposed (same as other tops) [safe]
- - Re-nicing own processes to rt/* will not work [safe]
- - Re-nicing non-own processes will not work [safe]
- - task_delayacct sysctl toggle (Ctrl-T) will not work [safe]
- - There are no other networking operations besides TASKSTATS from
NETLINK_GENERIC that would allow the unprivileged user do privileged tasks via
the higher capped binary [safe]
As a summary it seems that accepting the PR is 99% OK, but I'd prefer to get
more opinions before doing so.
With best regards,
b.
[1] https://src.fedoraproject.org/rpms/iotop-c/pull-request/1
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEumC8IPN+WURNbSUAE2VyCRPS8i0FAmIRkDEACgkQE2VyCRPS
8i32ww//dRzxVtff8+8qQ2ujLwf49ZigGdawkgdnJRuE+0oBDV30yycENblSLNWB
8FlidJcA+ZkoWf9WyoRvXydPcnuEhsr7y9UxyS/XA6l4iHHpUn7SJ/i79KAmVb8J
uuyWDBa23fZ4P22fy8/EklCzACWDeiYwS/jv+fwr8oLjEZ6nG+kjmMDIx5I2oA8J
vAfhCRLSTBXTQnWRs9MMxMIjQ9dcTvzOdv8ZPq+lVJuG6xrinLrH00XWLmDC7Dgh
/Ie2hvuHFCmId8BBAN5I47bh57ly4aZH0QKVpQL7x5bOYJDF1R27NHW660MxFZay
4xCZwYkLBcUtcm9R9SG8cZCd0nDptMRwmpvxu26QgFFl5hJgngdq4xmp3xsS/W2Y
JmQ7eTB+ypCVzd0QiQNHIfP1I+6NQbbakA+YIfiT9Uk1Z610IsO3cGW3tr2mSiBW
5/2fb2kU/vK4f2QPFwXJU8PYdJO/c9/zTFoRHomWG/MQx0zhNM8h0sK1tdxLp4V2
wuU/8wihpJx+rAofbmf2FrLowRYshiKqKeGYEWiWHLUAqWWKlBXkBiV5PY8l/YNx
Ta8Kd9aK00aezFmYa3TOHQyJYBuChdp/zqYfhRfRveXKj3TJMRW9MlgDtvuXXfUu
ukpSZWgR8twIhh+1QlS5rWZILIyVcdd0lNOSUYb2/i41bSREXkA=
=EJ2s
-----END PGP SIGNATURE-----
2 years, 3 months
Fedora 36 compose report: 20220223.n.0 changes
by Fedora Rawhide Report
OLD: Fedora-36-20220222.n.1
NEW: Fedora-36-20220223.n.0
===== SUMMARY =====
Added images: 0
Dropped images: 0
Added packages: 0
Dropped packages: 0
Upgraded packages: 0
Downgraded packages: 0
Size of added packages: 0 B
Size of dropped packages: 0 B
Size of upgraded packages: 0 B
Size of downgraded packages: 0 B
Size change of upgraded packages: 0 B
Size change of downgraded packages: 0 B
===== ADDED IMAGES =====
===== DROPPED IMAGES =====
===== ADDED PACKAGES =====
===== DROPPED PACKAGES =====
===== UPGRADED PACKAGES =====
===== DOWNGRADED PACKAGES =====
2 years, 3 months
rpmlint 2.x totally bogus output on debuginfo sub-pkgs
by Hans de Goede
Hi All,
I'm wondering if I'm the only one who is seeing quite a few bogus
warnings / errors getting thrown by rpmlint when run on C/C++
debuginfo sub-pkgs ?
And assuming I'm not the only one I'm wondering if there are some
plans to address / fix this ?
I tend to always run rpmlint as part of my workflow to avoid
unnecessary mistakes getting pushed out, but all the new
false-positive errors/warnings make this a lot more painful
then it used to be.
Regards,
Hans
2 years, 3 months
Orphaned magic-wormhole + its python deps
by Fabio Valentini
Hi everyone,
I have just orphaned magic-wormhole (the original one written in
Python) and its dependencies. I no longer use it, I have no time to
fix the packages for new Python versions, and upstream is pretty much
dead since they started porting the project to Rust.
- python-magic-wormhole
- python-magic-wormhole-mailbox-server
- python-magic-wormhole-transit-relay
- python-txtorcon
- python-spake2
- python-hkdf
There is an alternative Go implementation of the "Wormhole Protocol"
(wormhole-william), for which eclipseo already submitted a review
request. It seems to be better maintained than the Python original, if
we want to have a Wormhole client in Fedora:
https://bugzilla.redhat.com/show_bug.cgi?id=1922806
The official port of magic-wormhole to Rust also seems to be
progressing, we might want to package that one instead once it's
released:
https://github.com/magic-wormhole/magic-wormhole.rs
Fabio
2 years, 3 months
Question about Fedora Package Naming
by Hirotaka Wakabayashi
Hello, I have a question about Fedora Package Naming.
php-guzzlehttp-guzzle's version is 5.3.4, which is already EOL version by upstream. The latest version is 7.4.1.
https://src.fedoraproject.org/rpms/php-guzzlehttp-guzzlehttps://github.co...
In this situation, if I want to package the 7.4.1. version, should the package name be php-guzzlehttp-guzzle7? Or should I submit a patch to change the php-guzzlehttp-guzzle version? I think php-guzzlehttp-guzzle should be upgraded because EOL products potentially contain security issues, but most users probably doesn't know the package is EOL or not when they install it.
Regards,
Hirotaka
2 years, 3 months