I want to create a named FIFO using systemd-tmpfiles as specified in the manual at tmpfiles.d | p,p+. I am able to create the fifo but the issue is with the user and group of that named fifo. Here is how I am defining it in conf file:
p+ /run/reboot 0644 system system - -
But the fifo is always created as root.root even if I specify it as system system in the conf file.
If I run the systemd-tmpfiles-setup.service script after bootup, then it the fifo is with system.system privileges.
/bin/systemd-tmpfiles --create --remove --boot --exclude-prefix=/dev
So, either systemd-tmpfiles is creating it as root.root at bootup or some other service is changing permissions (not systemd-udev-trigger - tried masking this but no change).
For debug purpose, I ran this script (lsing) as ExecStartPort of systemd-tmpfiles-setup.service which does ls -la on /run and writes to /run/lsing.txt. Even there, I see the fifo is root.root,
ExecStartPost=/sbin/lsing
Need some help in debugging this issue. I am quite new to systemd.
Related
Consider the following, observed with bash 4.4 on a Linux 3.19 kernel:
# in reality, this may access files "nobody" isn't allowed
get_a_secret() { printf '%s\n' "This is a secret"; }
# attach a process substitution reading the secret to FD 10
exec 10< <(get_a_secret)
# run a less-privileged program that needs the secret, passing it the file descriptor.
chpst -u nobody:nobody -- cat /dev/fd/10
...or the shorter/simpler:
chpst -u nobody:nobody -- cat <(get_a_secret)
Either fails in a manner akin to the following:
cat: /proc/self/fd/10: Permission denied
So, two branches to this question:
What's going on here?
Is there a way to get the desired behavior (passing the ability to read the secret through to the single child process being invoked in a way that doesn't persistently expose that secret to other processes running as "nobody") without exposing the FIFO's output to other processes?
(Yes, I'm well aware that I need to lock down ptrace and /proc/*/mem to prevent another process running as "nobody" from pulling the secret out of the client as it's being read; that said, that's (1) something I can do, and (2) when the process is only run before any potentially-attacker-controlled executables are invoked, less exposure than allowing any process running as nobody to pull the secret out of /proc/*/environ for the full duration of that process).
The following workaround avoids this issue:
exec 10< <(get_a_secret)
chpst -u nobody:nobody -- sh -c 'cat <&10'
Note the redirection being written as <&10 -- not </dev/fd/10 or </proc/self/fd/10 (on platforms which provide /dev/fd -- on platforms without this facility, bash rewrites it into a fdup2() call).
An answer with an explanation of the behavior (and perhaps a workaround that allows programs that don't accept a FD number as input to act on the read side?) would be in a position to supercede this one. :)
I'm working on Linux Kernel 3.14.28 build with Buildroot for an embedded device.
In /dev/, all ttys are root:root and not root:dialout like a standard Linux. So it is not possible to access any ttyX without being logged as root.
How can I change the tty group permanently to root:dialout? I try to change it with chown command, but it became root:root again on reboot.
TL;DR: choose mdev as your device manager, and use the tty group instead of dialout.
The kernel's devtmpfs creates device nodes with a default name, owner and permissions. It also sends out a uevent when the node is created, which allows a uevent handler to change the name, ownership or permissions, or do anything else it wants. Previously this was called the hotplug system, but nowadays it's much more generic.
Buildroot offers the choice between three uevent handlers: mdev, which is part of busybox, eudev which is a standalone udev fork, and udev which is part of the systemd init system. These handlers are configured with rules files that specify what to do with a specific type of device when it appears.
For your specific need, mdev is the best choice since it is very simple, easy to understand, doesn't take up much space, and the default configuration is sufficient. In Buildroot's menuconfig, go to System configuration → /dev management and select Dynamic using mdev. Then rebuild your root filesystem. It will now be populated with the mdev binary (part of busybox), an init script to start it, and a default rules file in /etc/mdev.conf. This default file contains:
tty[0-9]* root:tty 660
This means that the tty devices will get their group changed to tty and their permissions to group read and write. So you can just make sure that the logged in user belongs to the tty group, and Bob's your uncle.
If the default mdev.conf file is not sufficient for you (for instance, if you really need the group to be dialout), then you can create a filesystem overlay, copy package/busybox/mdev.conf to /etc/mdev.conf and modify it as needed. Full documentation on the mdev.conf format can be found in the busybox sources.
devtmpfs always sets permissions to 0600 and makes it up to udev (or whatever runs after it) to maintain them. Its source confirms there's no way to override this explicitly (tty device driver overrides mode unconditionally in some cases).
Assuming you're using the Buildroot's default busybox as init, there's a way to do this with the following additional line in busybox's inittab (additional=must be present in addition to the essential lines (or their replacements) that are implied when there's no inittab - as they are no longer implied then there is):
::sysinit:<path_to_your_script>
with the script calling chown and chmod in loop.
But, it's better to handle this within the existing /etc/init.d/rcS (which is also run by BusyBox's init at sysinit by default).
As you can see from the stock buildroot's /etc/init.d/rcS, all you need to do is create a script /etc/init.d/S<whatever>.sh (where "whatever" places it into the desired position in the /etc/init.d/S??* output) with your commands:
for tty in /dev/tty*; do
chown root:dialout "$tty"
chmod ug+rw "$tty" #do not touch other bits
done
unset tty
I'm writing some code to replace TCP sockets with POSIX message queues. Sometimes the program will crash (still in development) and the queues that were created are not deleted (did not execute: mq_close() + mq_unlink()). This causes issues when I run the code again.
Is there a way to delete/remove these queues using the command line? I tried using: ipcs -q. This failed to list any queues.
I tried: lsof | grep queue-name. They did show up here.
Ideally, I'd like to use: ipcrm.
POSIX IPC objects are implemented as files in virtual file systems. These files can be listed and removed with ls and rm. To do this with POSIX message queues, we must mount the message queue file system using the following commands:
$ su
Password:
# mkdir /dev/mqueue
# mount -t mqueue none /dev/mqueue
# exit
I want to start a process that uses a USB hard drive once it gets inserted.
Since UDEV rules specifically mentions not to run long-time processes from RUN command, I send a FIFO message to my service which then opens the relevant process.
So the flow goes like this:
UDEV > runs action process > sends FIFO message to service > service gets message > runs the process who works with the HDD (aka HDD-PROCESS).
If I run my service from shell-1 and run 'action process' (the one that UDEV runs) from shell-2 everything works (including when trying it with udev).
But in deployment, the service is spawned from init, and when it does, the mount command fails saying "No such device".
I then detached "HDD-PROCESS" with fork and setsid, but that didn't help either.
from inittab:
::respawn:/opt/spwn_frm_init
ps relevant output:
PID PPID PGID SID COMM ARGS
31112 1 31112 31112 spwn_frm_init /bin/sh /opt/spwn_frm_init
31113 31112 31112 31112 runSvc /bin/sh /app/sys/runSvc
31114 31113 31112 31112 python python /app/sys/mainSvc.py
24064 1 24064 24064 python /usr/bin/python /app/sys/hdd_proc.py sdb1
everything runs under root (ps shows that too, I omitted that to save screen space).
So in short: when I run /opt/spwn_frm_init from shell, everything works. when I kill it and let it re-spawn from inittab, it doesn't and mount fails with error above.
UPDATE:
There is no problem when trying to mount an ext3 drive, but only on the NTFS one (using ntfs-3g).
Found it!
One of the differences between spawned process and another one who runs from shell is the environment variables which usually should be a problem when all I want is to call mount.
But when I noticed the problem happens only with the NTFS drive, it suddenly occurred to me that mount might need to call ntfs-3g so it worth checking if the second is accessible in the PATH variable.
which ntfs-3g led to /usr/local/bin/ntfs-3g which was mentioned in the default shell PATH but not in the one spawned from init.
To solve it, I added this /usr/local/bin to PATH in the "HDD-PROCESS" and mount began to work :)
A better error message in mount could have saved a lot of time here...
Can someone help me to understand how I need to configure buildroot, so that I will be able to successfully boot my own file system and login to it ?
I have a (seemingly) working kernel, and now I created my own file system (didn't change any settings in build root really, except set console to ttyAMA0), but the boot process just seems to hang without any problems to this:
....
[ 3.130000] VFS: Mounted root (ext3 filesystem) on device 179:2.
[ 3.140000] Freeing init memory: 144K
Starting logging: OK
Starting network...
ip: RTNETLINK answers: Operation not permitted
ip: SIOCSIFFLAGS: Permission denied
Whole boot log is visible here: http://paste.ubuntu.com/1364407/
I understand that /etc/inittab controls the boot process, the contents looks like this:
# Startup the system
null::sysinit:/bin/mount -t proc proc /proc
null::sysinit:/bin/mount -o remount,rw / # REMOUNT_ROOTFS_RW
null::sysinit:/bin/mkdir -p /dev/pts
null::sysinit:/bin/mkdir -p /dev/shm
null::sysinit:/bin/mount -a
null::sysinit:/bin/hostname -F /etc/hostname
# now run any rc scripts
::sysinit:/etc/init.d/rcS
# Put a getty on the sttyAMA0::respawn:/sbin/getty -L ttyAMA0 115200 vt100 # GENERIC_SERIAL
# Stuff to do for the 3-finger salute
::ctrlaltdel:/sbin/reboot
# Stuff to do before rebooting
null::shutdown:/etc/init.d/rcK
null::shutdown:/bin/umount -a -r
null::shutdown:/sbin/swapoff -a
Any advice on what is wrong in my configuration ?
Any tips on where I could get a good overview of "the usual necessary configurations" needed when creating my own linux system ?
This problem was raised by the submitter on the Buildroot mailing list. The solution was that the submitter was using Buildroot the contents of output/target directory directly as its root filesystem, even though the Buildroot documentation explicitly tells not to do so. This is because Buildroot does not run as root, and therefore cannot create device files or adjust permissions/ownerships properly in output/target. These steps are done when creating the root filesystem images, thanks to a magic tool called fakeroot.
Therefore, if someone wants the root filesystem to extract on a SD card partition or something like that, one should ask Buildroot to generate a tar image, and then extract it as root in the SD card partition.
Since this problem was quite common, we have now added a file in output/target called THIS_IS_NOT_YOUR_ROOT_FILESYTEM which contains details about this issue. See http://git.buildroot.net/buildroot/commit/?id=9226a9907c4eb0fffab777f50e88b74aa14d1737.