I have created a system account that's used by some process specifically. I want to set umask 002 for it. For regular user account, I usually put configuration like this in .profile. This approach is not suitable for system account, as .profile is sourced at login and system account doesn't require login.
Where can I set umask 002 for system account?
On most Linux systems, it is usually set in /etc/profile, but it can also be set in /etc/bashrc.
The latter gets sourced for all bash script invocations, not just logins.
However, if the system process is not started from a bash script, then you'll need to use a PAM configuration.
edit /etc/profile and try this:
if [ `id -u` -eq $user_id_to _change ]; then
umask 002
else
umask 022
fi
of course you have to change $user_id_to_change to the user id of which you want to change the umask. than reboot.
this code snippet defenitly works with "normal" users. cant imagine, why this shouldnt work with system users.
Related
I have been looking for a solution to setup an environment variable, that is non-persistent after reboot, but still accessable system wide. Anyone with a solution (bash)?
The reason is that I want crontab etc. to use these variables (after they have been set once in a single session). But, if the power goes or the disk is taken physically the variable (a password) is not found in the file system. (It's a Raspberry Pi backup server).
So far I have considered using Screen (with no real luck), and is considering a script in /etc/profile.d
The reason is that I want crontab etc. to use these variables (after they have been set once in a single session). But, if the power goes or the disk is taken physically the variable
So store the password in memory, assuming that memory is cleared after power loss. Ex. use shared memory or tmpfs filesystem. First script to setup the password:
#!/bin/bash
# setup_password.sh
if ! findmnt /srv/mypassword >/dev/null; then
mount -o tmpfs tmpfs /srv/mypassword
fi
printf "%s\n" "$1" > /srv/mypassword/password.txt
and script you execute from cron:
#!/bin/bash
if ! password=$(cat /srv/mypassword/password.txt); then
echo "ERROR: password not setup" >&2
exit 2
fi
: continue and use the password "$password"
If your /tmp is a tmpfs, and probably it is, just store the password in /tmp...
if /usr/bin/bash has the suid bit set
why does my euid change to root only when I use the -p option like so /usr/bin/bash -p
what does this -p option stand for?
and when you spawn a bash shell from a suid binary why euid is set to root and why not uid?
From the documentation:
-p
Turn on privileged mode. In this mode, the $BASH_ENV and $ENV files are not processed, shell functions are not inherited from the environment, and the SHELLOPTS, BASHOPTS, CDPATH and GLOBIGNORE variables, if they appear in the environment, are ignored. If the shell is started with the effective user (group) id not equal to the real user (group) id, and the -p option is not supplied, these actions are taken and the effective user id is set to the real user id. If the -p option is supplied at startup, the effective user id is not reset. Turning this option off causes the effective user and group ids to be set to the real user and group ids.
This is done because setuid shell scripts have been a common source of security bugs. So the programmer is required to use the -p option to indicate that they really need the privilege escalation, e.g. by using
#!/usr/bin/bash -p
Without this, setting the suid bit on /usr/bin/bash itself would be an enormous security hole, since most scripts don't take the necessary precautions needed when running with elevated permissions.
I'm asked to take away the permission for the root user to execute a bash script, is that even possible? Actually how would one take away any permissions from some user? with chmod I could modify it for the current logged in user, but not for root.
If you are simply looking for a small safeguard, an obstacle to accidentally running the script as root, write the script to voluntarily exit if run as root. Add the following to the beginning of the script:
if [[ $EUID == 0 ]]; then
printf 'Do not run this script as root\n' >&2
exit 1
fi
You can't do that, root can do everything. But there are some measures to make it difficult. You can use the following command in ext{2-4} filesystems:
chattr +i script.sh
Doing this the file can't be modified, but it can be unlocked using chattr -i script.sh
Other thing you can do is: Put the script you want unchangeable for root on remote server and mount it via NFS. If the server does not offer write permissions that locks out the local root account. Of course the local root account could just copy the files over locally, unmount the remote stuff, put the copy in place and change that.
You cannot lock out root from deleting your files. If you cannot trust your root to keep files intact, you are having a social problem, not a technical 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
In order to improve security a bit, I'd like to run the keychain agent as a different user. This shall prevent users who hijack my system from gaining the actual private key, while maintaining the ability to use it to authenticate ssh and scp connections.
What have I tried?
I created a user called agent who should store the private key and run the ssh-agent process. I created a script file to set up the right permissions for the socket:
#!/bin/sh
export EVAL=$(keychain --eval -q)
eval $EVAL
chmod 770 $(dirname $SSH_AUTH_SOCK) $(dirname $GPG_AGENT_INFO)
chmod 660 $SSH_AUTH_SOCK $(echo $GPG_AGENT_INFO | sed 's/:.*//')
echo $EVAL
And call that one in my .bashrc, eval'ing it.
But when I now connect to a server via ssh, I get
$ ssh server
Error reading response length from authentication socket.
Any hints?
keychain seems to use either an already running ssh-agent or gpg-agent, and start one if needed.
ssh-agent checks if the user id of the running process matches the id of the user connecting through the unix domain socket (with the exception of root). If you run the agent in debug mode you'll see the corresponding error message. In this case the socket is immediately closed, so you'll get the error message you mention above - you're probably using ssh-agent on your system. That means what you try to do won't be possible using ssh-agent (unless you don't modify it).
It should work if you use gpg-agent with the --enable-ssh-support option as replacement for ssh-agent, but you should be aware that this setup doesn't really increase security. With the permissions you're trying to set, it would allow every user that has access rights to the socket the to authenticate as you using the added key once it has been unlocked, so it's actually less secure.