Hot answers tagged setcap
Until you asked the question I never even heard of this facility in Unix (file capabilities). I found this link which looks to have the solution as to how to make ld.so trust your shared libraries: JDK-7157699 : can not run java after granting posix capabilities excerpt from that post When one is raising the privileges of an executable, the runtime ...
OpenSSH will flat-out refuse to bind to privileged ports unless the user id of the logged in user is 0 (root). The relevant lines of code are: if (!options.allow_tcp_forwarding || no_port_forwarding_flag || (!want_reply && listen_port == 0) || (listen_port != 0 && listen_port < IPPORT_RESERVED && pw->pw_uid != ...
You could use su in your startup scripts: su -s /bin/sh -c '/usr/bin/somedaemon' someuser Another solution would be to start the daemon using cron.
You should just call: sudo -u username your_daemon_name in the init script, as root runs the init script it will not ask for a password but run the scripts as username.
The Java executable relies on a feature that is disabled by the kernel when the executable acquires additional permissions or capabilities, as a safety measure. If you want to use this executable as non-root then you'll need to add the location of libjli.so to your loader configuration, located in /etc/ld.so.conf*.
As mentioned in this Kernel Mailing List message, whether a process needs extra security is checked in cap_bprm_secureexec() of the kernel file security/commoncap.c, which does check for capabilities. This is then exported to the process via the auxiliary vector. This can be accessed/tested via getauxval(AT_SECURE). I inserted getauxval(AT_SECURE) into a ...
Setting the hostname in linux is done via the sethostname(2) syscall. And /bin/hostname is a bare wrapper around this syscall (and a few related syscalls). /etc/hostname is supposed to be read during the boot process by some script, who subsequently runs /bin/hostname to complish its job. CAP_SYS_ADMIN is one of linux capabilities(7), allows a thread to ...
And one last desperate syntax guess pays off: # setcap cap_net_bind_service,cap_sys_boot=+ep /usr/bin/nodejs # getcap /usr/bin/nodejs /usr/bin/nodejs = cap_net_bind_service,cap_sys_boot+ep
It turns out that setting +i on the wrapper does not add the capability to the CAP_INHERITABLE set for the wrapper process, thus it is not passed through exec. I therefore had to manually add CAP_DAC_OVERRIDE to CAP_INHERITABLE before calling execl: #include <sys/capability.h> #include <stdio.h> #include <unistd.h> int main(int argc, char ...
If you are using systemd (as of today, only Slackware, Ubuntu and Debian among Linux distributions are using anything else) you can set the user/group in its .service file (see systemd.service(5), systemd.exec(5), and browse through the copious documentation here).
Only top voted, non community-wiki answers of a minimum length are eligible