Bug#969372: INFO: Bug#969372: uwsgi-emperor: SysV init script does nothing
Okay, this is quick-and-dirty because I didn't have a great deal of time and I'm not /that/ great with systemd service files to begin with. --- [Unit] Description=uWSGI Emperor After=syslog.target [Service] ExecStart=/usr/bin/uwsgi --ini /etc/uwsgi-emperor/emperor.ini RuntimeDirectory=uwsgi Restart=always KillSignal=SIGQUIT Type=notify StandardError=syslog NotifyAccess=all [Install] WantedBy=multi-user.target There's serious room for improvement there -- the usual way for running the Emperor is in Tyrant mode and setting it to retain setuid/setguid capabilities before switching down to a non-privileged user; I think it would be possible to assign it those capabilities in the service file and start it unprivileged otherwise, but I'm not good enough to bash that out safely. Hope this helps, and thanks for the excellent job you guys do, --Rens.
Bug#969372: INFO: Bug#969372: uwsgi-emperor: SysV init script does nothing
Hello, I've come across the same bug while trying to set up a new service at work. After some digging (we've currently got a mishmash of Jessie and Buster systems, not all of them have been upgraded yet) I discovered that the init script, such as it is, is identical in all versions, and it is not actually the problem. Running the init script manually gave the following output: rhouben@networking-lab-rh:/var/log/uwsgi$ sudo /etc/init.d/uwsgi-emperor start [ ok ] Starting uwsgi-emperor (via systemctl): uwsgi-emperor.service. ... Whereas on a system still running Jessie I got: shadur@radius-srv-dc25:~$ sudo /etc/init.d/uwsgi-emperor restart [] Restarting uWSGI Emperor server: uwsgi[uWSGI] getting INI configuration from /etc/uwsgi-emperor/emperor.ini setting capability setgid [6] setting capability setuid [7] . ok The issue arose because the init script isn't so much a script as it's a set of variables plugged into the init.d helper scripts, and /those/ have changed drastically from Jessie to Buster and onwards to call systemctl -- but in uwsgi-emperor's case there doesn't appear to /be/ a systemd service file to call on, so it quietly fails and does nothing at all. I'm currently writing at least a rudimentary systemd service file for uwsgi-emperor to see if that makes it work; I can share it once I finish if you'd like. --Rens Houben. SYSTEMEC BV Marinus Dammeweg 25, 5928 PW Venlo Postbus 3290, 5902 RG Venlo Industrienummer: 6817 Nederland T: 077-3967572 (Support) K.V.K. nummer: 12027782 (Venlo) Neem een kijkje op onze vernieuwde website<https://www.systemec.nl> [Systemec Datacenter Venlo, Nettetal en D?sseldorf]<https://www.systemec.nl> ISO/IEC 27001:2017 gecertificeerd door Digitrust, registratienummer DGT2020092101 NEN 7510-01:2017 gecertificeerd door Digitrust, registratienummer DGTN2020092101<https://www.systemec.nl/nl/over-systemec/certificeringen> [Systemec Helpdesk]<https://support.systemec.nl> Helpdesk<https://support.systemec.nl> [Aanmelden nieuwsbrief]<https://www.systemec.nl/nl/nieuwsbrief> Aanmelden nieuwsbrief<https://www.systemec.nl/nl/nieuwsbrief> Volg ons op: [Systemec Twitter] <https://twitter.com/systemec> [Systemec Facebook] <https://www.facebook.com/systemecbv> [Systemec Linkedin] <http://www.linkedin.com/company/systemec-b.v.> [Systemec Youtube] <http://www.youtube.com/user/systemec1>
Bug#743483: apache2-mpm-itk: AssignUserID is ignored in favor of file ownership.
Package: apache2-mpm-itk
Version: 2.2.22-13+deb7u1
Severity: grave
Tags: security
Justification: user security hole
Dear Maintainer,
I was setting up a new webhosting server using the latest Wheezy version,
and in particular moving away from suexec/fcgid and to mpm-itk for performance
reasons. During one of the tests with a php script containing just the line
?php print get_current_user() ?
I was shocked to discover that the return value was 'root' rather than
'testclient' because I'd created the file as root ('testclient' doesn't get
a shell login) and the script's UID was set to the file owner rather than the
explicitly stated AssignUserID testclient webclients.
I ran a second test, this time placing the script in /var/www and adding
'AssignUserID www-data www-data' to /etc/apache2/sites-enabled/000-default,
and observed the same behavior.
I'm breaking my head over whether I might have made a mistake during
configuration, but this is a near-pristine server setup -- and either I've
done something very badly wrong or this is a serious security problem with
mpm-itk, especially if someone can write a script in their webhosting docroot
and then chown it to root.
-- Package-specific info:
List of enabled modules from 'apache2 -M':
alias auth_basic authn_file authz_default authz_groupfile
authz_host authz_user autoindex cgi deflate dir env evasive20 mime
negotiation php5 reqtimeout setenvif status
List of enabled php5 extensions:
memcached pdo
-- System Information:
Debian Release: 7.4
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.13-0.bpo.1-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages apache2-mpm-itk depends on:
ii apache2.2-bin 2.2.22-13+deb7u1
ii apache2.2-common 2.2.22-13+deb7u1
apache2-mpm-itk recommends no packages.
apache2-mpm-itk suggests no packages.
-- no debconf information
000-default
Description: inode/symlink
Bug#622309: udev: Network, sound and X input broken
This bug still exists in the latest unstable version of udev on my system. At boot time, it gives the following output (transcribed from a photo taken with my cellphone camera): Starting the hotplug events dispatcher: udevdudevd[435]: error: directory '/run/udev/ not writable, for now falling back to '/dev/.udev/' udevd[435]: bind failed: Address already in use error binding udev control socket udevd[435]: error binding control socket failed! If I boot to maintenance mode and log in with the root password, then manually stop and restart udev it functions and boots up correctly, however. -- Rens Houben |opinions are mine Resident linux guru and sysadmin | if my employers have one Systemec Internet Services. |they'll tell you themselves PGP key at http://proteus.systemec.nl/~shadur/shadur.key.asc -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#315467: Quagga explicitly flushes all routes when upgrading or restarting
I just ran into this bug, and read the e-mail discussion in the bts archive, and I find myself wondering if you actually understand the cause of the problem here at all... All of the quagga daemons can be instructed /not/ to flush their routes upon exit; this is documented in their respective manpages (see the --retain flag). What's causing the routes to temporarily disappear is the fact that you *explicitly flush them* in the init.d script. Let me quote a bit of it: stop|0) # Stop all daemons at level '0' or 'stop' stop_prio 0 $2 echo Removing all routes made by zebra. ip route flush proto zebra ;; restart|force-reload) $0 stop $2 sleep 1 $0 start $2 ;; That ip route flush proto zebra line is what's doing the damage here, not some kind of underlying concept of what happens when a daemon is restarted. Or did you really think the quagga authors hadn't thought of that problem themselves? As it is right now, the version of quagga in debian has a very serious problem, and your attitude of it's not my fault others couldn't figure out the obvious in the email conversation on this bug really did not help matters. Fix this. It won't take you five minutes. -- Rens Houben |opinions are mine Resident linux guru and sysadmin | if my employers have one Systemec Internet Services. |they'll tell you themselves PGP key at http://marduk.systemec.nl/~shadur/shadur.key.asc signature.asc Description: Digital signature
Bug#340565: quagga: Repeat of #315467: So-called fix doesn't resolve the actual problem.
Package: quagga Version: 0.99.2-1 Severity: grave Tags: patch Justification: causes non-serious data loss The problem described in #315467 (all negotiated routes get dropped during a restart of quagga) is in fact *not* due to the simple concept of a daemon restarting as you implied -- in fact, the quagga authors already thought long and hard about that possible issue and allowed for it: When starting any of the quagga daemons with the --retain flag, that daemon will not flush its routes when exiting. The *real* cause of the problem is the explicit route flush you added in the /etc/init.d/quagga script at the stop case. It's not only unneccessary (because each daemon can be configured via /etc/quagga/debian.conf to either flush or retain its routes), it's dangerous. Removing line 225 and 226 from /etc/init.d/quagga fixes the problem without requiring a debconf prompt not to restart quagga ever. -- System Information: Debian Release: testing/unstable APT prefers stable APT policy: (900, 'stable'), (100, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.13 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages quagga depends on: ii adduser 3.79 Add and remove users and groups ii debconf [debconf-2.0] 1.4.59 Debian configuration management sy ii iproute 20041019-4 Professional tools to control the ii libc6 2.3.5-8GNU C Library: Shared libraries an ii libcap1 1:1.10-14 support for getting/setting POSIX. ii libncurses5 5.5-1 Shared libraries for terminal hand ii libpam0g 0.79-3 Pluggable Authentication Modules l ii libreadline5 5.0-11 GNU readline and history libraries ii logrotate 3.7.1-2Log rotation utility quagga recommends no packages. -- debconf information: * quagga/really_stop: true -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
