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 ...
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
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 != 0)...
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 ...
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.
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*.
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.
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 ...
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 ...
The capabilities are stored with the file entry in the directory (more precisely, they're in the file's inode, like other kinds of permissions). Nothing special happens during boot. As of GNU coreutils 8.23, the ls command doesn't know about Linux capabilities, so you won't find anything in its output to tell you that a program has capabilities set. Use the ...
See setcap(8), capabilities are set for the executable file. This works similar to (but with finer granularity than) SUID or SGID. Nowhere in "the booting process" is this handled; whenever the file is executed as a program, the resulting process gets the capabilities. Yes, leaving old versions of the file with elevated privileges is a serious security risk,...
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).
I meet the similar problem, so the solution I ended up is to add DNAT rule to the OUTPUT chain of nat table: iptables -t nat -A OUTPUT -d 127.0.0.0/8 -p tcp --dport 80 \ -j DNAT --to-destination :8080 This rule effectively replaces the destination port 80 with 8080 for all locally generated tcp packets. If you wish to allow any incoming connections to be ...
Only top voted, non community-wiki answers of a minimum length are eligible