The bugs exist in ‘journald’ service, tasked with collecting and storing log data, and they can be exploited to obtain root privileges on the target machine or to leak information. No patches exist at the moment.
Source: Linux systemd Affected by Memory Corruption Vulnerabilities, No Patches Yet
So in order to trigger this behaviour, someone with root-level privileges needs to edit a Unit file and enter a “invalid username”, in this case one that starts with a digit.
But you need root level privileges to edit the file in the first place and to reload systemd to make use of that Unit file.
Source: Giving perspective on systemd’s “usernames that start with digit get root privileges”-bug
It’s an obvious bug (at least on RHEL/CentOS 7), since a valid username does not get accepted by systemd so it triggers unexpected behaviour by launching services as root.
However, it isn’t as bad as it sounds and does not grant any username with a digit immediate root access.
remove systemd supportsystemd people are not willing to play nice with the rest of the world. Therefore there is no reason for the rest of the world to cooperate with them.
Source: busybox – BusyBox: The Swiss Army Knife of Embedded Linux
How do you recognize a good API? It’s tough, but one thing is sure, a good interface allows easy swapping of components. If it doesn’t allow easy swapping of components, it’s not a good interface.
Source: 9 – systemD: Interfaces last longer than code – Slashdot
Throughout systemd there is a lack of understanding of proper interfaces. Making the GUI depend on a particular init system is a particularly obvious example of poor design, but the code was written from a ‘code first’ perspective rather than an ‘interface first’ perspective.
You can use the mailq command sendmail -bp command to display a summary of the mail messages queued for future delivery. Type the following command:
# mailq
via Sendmail: Clear / Delete / Flush Mail Queue.
A service in a local server started to send email through my main server back to the originating server causing many errors in /var/log/maillog of my main server. Each attempt added a message to its message queue that was blocked due to a problem with sendmail on the originating server. The email being sent was sent automatically by a VOIP service I was testing on that originating server (not good).
You can cd to /var/spool/mqueue and delete all files if you want to get rid of all messages in the queue:
# cd /var/spool/mqueue/
# ls
# rm *
The above sequence cleared the queue so sendmail stopped trying to send those messages to a broken server at the destination.
Sendmail wouldn’t start. OS Fedora 19 so it’s running that new systemd for service startup. Here are pertinent error messages in /var/log/messages:
Nov 17 21:23:39 ana systemd[1]: Starting Sendmail Mail Transport Agent... Nov 17 21:23:39 ana sendmail[1555]: -bd is not supported by sSMTP Nov 17 21:23:39 ana systemd[1]: PID file /run/sendmail.pid not readable (yet?) after start. Nov 17 21:23:39 ana systemd[1]: Failed to start Sendmail Mail Transport Agent. Nov 17 21:23:39 ana systemd[1]: Dependency failed for Sendmail Mail Transport Client. Nov 17 21:23:39 ana systemd[1]: Unit sendmail.service entered failed state.
I did a lot of googling to find someone in a similar situation to no avail. I then looked into sSMTP and why that was being called instead of good old sendmail. After
#yum erase sSMTP
thus purging that service entirely from the system, sendmail starts in this Fedora 19 VM and works (knock on wood).