I am facing problem while querying DNS using getaddrinfo() API under a process initiated by systemd. Despite having nameserver entry in /etc/resolv.conf, the query fails to resolve. After few system call traces, it is found that the problem is due to systemd resolution. It seems like, for a process inited by systemd, the getaddrinfo() DNS query routed via systemd while in stand alone mode (i.e. spawned by shell), the query happens normally. I changed the /etc/systemd/resolved.conf to add my DNS address and restarted systemd-resolved. Now the DNS query works properly.
Is there anyway to bypass systemd for getaddrinfo() [ex: passing extra flags to hints], and get the work done in usual way?
In my opinion, the genuine getaddrinfo() call should always use glibc.
My best guess is that the supposed correlation with systemd process initiation is entirely false. On a systemd system all ordinary processes are either directly or indirectly initiated by systemd.
Network name resolution performed by glibc is not only driven by /etc/resolv.conf but also by /etc/nsswitch.conf. You will probably see resolved mentioned in that file.
Related
I have two Linux VMs. They all start the sshd service on the same IP. When one machine is down, you can login on another VM with the same IP. However, the other VM will not be listening to that IP because it does not already exist.
I must restart the sshd service manually. However, I can not login the VM if sshd is not started. I found a solution by setting ip_nonlocal_bind to 1.
I googled the description of ip_nonlocal_bind in kernel.org:
ip_nonlocal_bind - BOOLEAN
If set, allows processes to bind() to non-local IPv6 addresses,
which can be quite useful - but may break some applications.
Default: 0
Last line says but may break some applications, and I worry this could break the application I'm running on my VM.
My VM mainly acts as a router.
Finally, I want to know: how can ip_nonlocal_bind break applications?
The kernel documentation says that ip_nonlocal_bind may break some applications because as the name implies it allows to bind() on addresses that are not local to the machine. If this setting is enabled, and an application makes the (wrong) assumption that the inbound address is local to the machine, this could cause it to crash or in any case handle the connection wrongly.
The documentation says that this could break some applications because prior to the setting being introduced (in kernel v4.3 if I am not mistaken) applications could safely assume that bound addresses were local.
I wouldn't worry about it in your case since as you say your machine merely acts as a router so basically the whole routing job is done by the kernel itself.
I have created a script and I want it to be virtually "immune" to SIGSTOP.
I understand that both SIGKILL and SIGSTOP cannot be trapped or ignored.
I know that the init system for Linux cannot receive a "fatal" signal due to it having the SIGNAL_UNKILLABLE flag on its signal struct flags (although the latter half of that sentence flies over my head for the most part).
I'm willing to edit my kernel to grant this script immunity, the only problem is that I don't know how.
So, my question is, is there a way to nullify SIGSTOP for a certain script/process?
I was able to deal with SIGKILL thanks to the Restart parameter in the service file for my script (using systemd), and while I have scrolled through the manuals looking for something similar for suspended processes, I haven't found anything yet.
Is there anything similar to Restart=always for process suspension caused by SIGSTOP?
I would rather not have to go through the process of changing things in or related to the kernel, but if it's the only way I will.
Thanks.
Okay so the best solution I can come up with is SELinux.
SELinux is a kernel add-on created by the NSA that was later released to the public. It is commonly used on Linux systems and comes by default on Android devices. SELinux allows the creation of "contexts". Contexts are an additional label provided to files and processes that allow the subdivision of responsibility and permissions.
How does this solve your problem? Well, you can limit your SELinux permissions for your user processes (even for the root user) so that you're not even allowed to signal this other process at all. In fact, you can prevent any interaction with it whatsoever. If you'd like, you could go so far as to prevent yourself from even being able to turn SELinux off (although it's probably better that you don't if you can avoid it from an operational perspective). This is at some level probably the closest you'll get to a solution that is anywhere near the range of not-hackable. That being said, SELinux setup and configuration for this purpose is not exactly a walk in the park. Documentation is limited (but exists), distro-specific, and in some cases even esoteric. I do have some experience with SELinux myself.
Edit:
Doing some quick googling, it appears possible to install SELinux on Arch, but like most things on Arch, it requires some effort - more than should fit in a StackOverflow comment block. However I'll briefly describe your set of goals here once SELinux is installed:
Determine the context that you are currently in. Using the "id" command should provide this context.
Use a context process transition so that when you execute your script, that script runs in a new context. You will probably need to create a new context for your script to run in.
Create sepolicy rules allowing that script to interact with your processes however you need. Perhaps this includes the ability to kill other processes in a different context, or read from a tcp port using sniffing, etc. etc. You can use the audit2allow program to help you create these rules.
By default, SELinux denies anything it doesn't explicitly allow. Your goal now is to make sure that everything you might want to do on your system is allowed, and add policy rules to allow all those things. Looking at the SELinux audit logs is a great way to see everything SELinux is complaining about - it's your job to go through and convert all those audit failures into "allow" rules.
Once all that is done, just make sure not to "allow" whatever context your processes/shell start in from being able to kill or signal the context that your script runs in, and you should be done. Now trying to SIGSTOP or SIGKILL should generate a "Permission denied error".
I need to find for local tcp-connections/Unix-domain-connections the client process that starts the connection in the most effective way possible.
I currently have a solution for this implemented in a driver, that intercept both accept and connect syscalls, match them, and finds out the client process.
Now I try to achieve the same without my own driver.
Different approaches I tried:
Linux auditing system plugin that intercept the appropriate syscalls and resolve the client in a similar manner. This method has 3 problems:
Each intercepted event flows from the kernel to the auditd process to some other intermediate process and only than to my plugin.
The audit rules are applies for all the plugins and audit-log - I can't define my own set of filtering rules. - which may cause on machines that uses the audit system for extreme inefficiency.
It requires that audit to be installed on the machine (which is not default for many Linux distributions).
Imitate netstat/lsof - In order to find the process that holds a connection, they iterate the entire procfs mount - this makes sense, because after connection establishment, each connection could belongs to more than one process.
This approach is extremely not effective if I want to do so for each connection establishment.
I thought to try one of the LSM (Linux security modules) solutions - but I am currently unfamiliar with it - Is their a LSM that can pass the kernel events for a running application for a "decision"?
I will be happy to hear suggestions and other comments that could lead me to a reasonable solution for my original goal.
Found an option that suits my needs for Unix-domain-sockets only - if runnning code in the server side is a possability (as in my case) one can use getsockopt in the following manner:
getsockopt(fd, SOL_SOCKET, SO_PEERCRED, &cr, &len)
More details in http://welz.org.za/notes/on-peer-cred.html
I need to start a service and (later) detect if it running from within a C++ program. Is there a simpler approach than invoking systemctl with suitable arguments and parsing the output?
The source of the service is entirely under my control. (Currently it is written in bash, but a C++ wrapper is entirely possible.)
(I've had a brief look at DBus - it is clearly very powerful, but fails the "simpler" test.)
The source of the service is entirely under my control. (Currently it is written in bash, but C++ is entirely possible.)
The code is for an embedded device running a variant of Debian Jessie. Portability is not a major concern (but obviously the answer will be more useful to others if it is portable).
Most programs are written with the other way in mind (even in pre-systemd days).
Typical services (those having and started with a single server process) are writing their PID (as an ASCII number on a single line) in some /var/run/foobar.pid file at their startup. If you adopt such a convention in your service, you can read that file using fscanf then check that the process is running with kill(pid, 0); (of course, you cannot be certain that it is the same service, but it probably would be).
I have right now more than 20 files matching /var/run/*.pid, notably /var/run/sshd.pid & /var/run/atd.pid
So, assuming you can improve the code of your service FooBar (if that functionality is not there), change its code to write its pid into /var/run/foobar.pid; this is a documented convention.
If you can change the service, you might have it providing some ping or nop functionality; so you would add to it some RPC facility which justs check that the service is running (and could also give some additional information, like the version of the program, etc.). Most existing Linux services have such feature.
Why not flip the problem around? No parsing would be needed.
ttm.update.service will do the following.
systemctl stop ttm.service
systemctl disable ttm.service
#do you update here
#if the service configs changed do
systemctl daemon-reload
systemctl enable ttm.service
systemctl start ttm.service
ttm.service would never have to worry about the updater, it just runs and do it's job.
Context:
On a linux (RedHat family) system, I have an init-script-based service that is started/stopped manually most of the time, and in general is only run in response to specific, uncommon situations. The init scripts are thin wrappers around code that I do not have control over.
If the service is killed without running the stop action on its init script, it is aborted uncleanly and leaves the system in a broken state that requires manual intervention to fix.
When the systems running the service shut down, they kill it uncleanly. I can register the service with chkconfig such that it gets shut down via the init script when the host shuts down; this solves the problem on a per-host basis.
Question:
I would like to automate the configuration of this service to stop-at-shutdown via Puppet.
How can I tell Puppet to register a service with chkconfig such that the service will be stopped via the init script when the system shuts down, but will not otherwise be managed by Puppet?
What I've Tried:
I made a hokey exec statement in Puppet that calls chkconfig directly, but that feels inelegant (and will probably break in some way I haven't thought of).
I played around with the noop flag to the service type in Puppet, but it didn't seem to have the desired effect.
Puppet does not have any built-in support for configuring which runlevels a service runs in, nor any built-in, generalized support for chkconfig. Ordinarily it is a service-installation responsibility to register the service with chkconfig; services that are installed from the system RPMs are registered that way.
Furthermore, chkconfig recognizes structured comments at the top of initscripts to determine which runlevels the service will run in by default, according to LSB convention. A proper initscript need only be registered with chkconfig to have the default runlevels set -- in particular, for it to be set to be stopped in runlevels 0 and 6, which is what you're after.
If you're rolling your own initscripts and deploying them manually or directly via Puppet (as opposed to packaging them up and installing them via Yum) then your best bet is probably to build a defined type that manages the initscript and its registration. You do not need and probably do not want a Service resource for it, but a File resource to put the proper file in place and an Exec resource to handle registration sounds about right.