Is there a way to configure a binary to be installed as "SUID" using automake/autoconf?
Is there any magick that can lead a make install to set the suid bit of a given binary target?
NOTE:
I am running a "fakerooted" make install inside a script to create a tar file.
I tried:
# Makefile.am
bin_PROGRAMS = my_bin
#...
install-exec-hook:
echo "#### Setting SUID for my_bin. ####"
ls -l $(DESTDIR)$(bindir)/my_bin
chmod 4755 $(DESTDIR)$(bindir)/my_bin
ls -l $(DESTDIR)$(bindir)/my_bin
echo "####-------------------------------####"
But with no success.
During make install I see:
#### Setting SUID for sudo_script. ####
-rwxr-xr-x 1 root root 8704 Mar 28 13:30 /install.pak/usr/bin/my_bin
-rwsr-xr-x 1 root root 8704 Mar 28 13:30 /install.pak/usr/bin/my_bin
####-------------------------------####
So one could think it is a problem with fakeroot, but if I move the chmod out of Makefile.am to my packaging script, it works. This is enough to convince me fakeroot is doing its job.
Thanks.
GAHH!!
Someone unconsciously put in my script, after $FAKEROOT make install:
$FAKEROOT chmod 755 $PAK_DIR/usr/bin/*
replacing all the permissions writen by make install.
Removing this line the install-exec-hook works as expected and the SUID bit is preserved...
(Were did I put my ax?...)
Related
I'm writing a Dockerfile to run ROS on my Windows rig and I can't seem to get this COPY command to copy to the container's user root or any sub directory there. I've tried a few things, including messing with the ownership. I know file is ugly but still learning. Not really sure what the issue is here.
This file sits next to a /repos dir which has a git repo within it which can be found here (the ros-noetic branch). This is also the location from which I build and run the container from.
Overall objective is to get roscore to run (which it has been), then exec in with another terminal and get rosrun ros_essentials_cpp (node name) to actually work
# ros-noetic with other stuff added
FROM osrf/ros:noetic-desktop-full
SHELL ["/bin/bash", "-c"]
RUN apt update
RUN apt install -y git
RUN apt-get update && apt-get -y install cmake protobuf-compiler
RUN bash
RUN . /opt/ros/noetic/setup.bash && mkdir -p ~/catkin_ws/src && cd ~/catkin_ws/ && chmod 777 src && catkin_make && . devel/setup.bash
RUN cd /
RUN mkdir /repos
COPY /repos ~/catkin_ws/src
RUN echo ". /opt/ros/noetic/setup.bash" >> ~/.bashrc
Expanding tilde to home directory is a shell feature, which apparently isn't supported in Dockerfile's COPY command. You're putting the files into a directory which is literally named ~, i.e. your container image probably contains something like this:
...
dr-xr-xr-x 13 root root 0 Jun 9 00:07 sys
drwxrwxrwt 7 root root 4096 Nov 13 2020 tmp
drwxr-xr-x 13 root root 4096 Nov 13 2020 usr
drwxr-xr-x 18 root root 4096 Nov 13 2020 var
drwxr-xr-x 2 root root 4096 Jun 9 00:07 ~ <--- !!!
Since root's home directory is always /root, you can use this:
COPY /repos /root/catkin_ws/src
You need to pay attention on the docker context.
When you build docker, you are adding the path to build your image.
If you are not on the / folder, your COPY /repos command won't work.
Try to change the docker context with that:
docker build /
I installed Puppeteer to use it in the generation of pdf / minuatures, but I can not activate and configure Chrome Linux Sandbox. Always the same error message :
(node:46) UnhandledPromiseRejectionWarning: Error: Failed to launch chrome!
[1208/055442.253403:FATAL:zygote_host_impl_linux.cc(116)] No usable sandbox! Update your kernel or see https://chromium.googlesource.com/chromium/src/+/master/docs/linux_suid_sandbox_development.md for more information on developing with the SUID sandbox. If you want to live dangerously and need an immediate workaround, you can try using --no-sandbox.
I followed the steps mentioned in the official documentation, but without success
# cd to the downloaded instance
cd <project-dir-path>/node_modules/puppeteer/.local-chromium/linux-<revision>/chrome-linux/
sudo chown root:root chrome_sandbox
sudo chmod 4755 chrome_sandbox
# copy sandbox executable to a shared location
sudo cp -p chrome_sandbox /usr/local/sbin/chrome-devel-sandbox
# export CHROME_DEVEL_SANDBOX env variable
export CHROME_DEVEL_SANDBOX=/usr/local/sbin/chrome-devel-sandbox
Try with
sudo sysctl -w kernel.unprivileged_userns_clone=1
It will allows you, as unprivileged user, to access the sandbox of chromium.
This is temporary and active only until reboot.
You likely have the setuid bit wrong because of the cp command :
$ sudo touch orig
$ ls -l orig
-rw-r--r-- 1 root root 0 févr. 11 23:31 orig
$ sudo chmod 4755 orig
$ ls -l orig
-rwsr-xr-x 1 root root 0 févr. 11 23:31 orig
$ sudo cp orig new
$ ls -l new
-rwxr-xr-x 1 root root 0 févr. 11 23:31 new
The setuid bit (4th character) was changed from s to x after cp.
On OSX Yosemite and the latest version of meteor (1.0.1), no matter how many times I uninstall and reinstall it, I can't seem to get it running without sudo. My user account is an administrator account. But meteor refuses to run without sudo. The errors I'm getting are all:
-bash: meteor: command not found
I've seen a few posts on here with similar problems. I've tried repairing disk permissions with disk utility. I've tried:
sudo chown -R $myUsername /usr/local/bin/meteor
I'm not sure what else I can do, because it seems to be a permissions issue. Does anyone have any suggestions?
Additional info that might help:
$ sudo which meteor
/usr/local/bin/meteor
$ sudo ls -l /usr/local/bin/meteor
-rwxrwxrwx 1 root wheel 3528 Dec 18 23:14 /usr/local/bin/meteor
$ ls -ld /usr/local/bin
drwx------ 6 502 wheel 204 Dec 18 23:14 /usr/local/bin
By the way, ls -l /usr/local/bin/meteor only works with sudo.
After we clarified the permissions of the meteor executable and its base directory,
the problem became quite clear:
The Meteor binary is located in /usr/local/bin/meteor
Your user didn't have permission to the directory /usr/local/bin
The steps to resolve:
Add permission on the base directory: sudo chmod +rx /usr/local/bin
If necessary, add the base directory to PATH: PATH=$PATH:/usr/local/bin
For future reference:
When you get this kind of error: -bash: XYZ: command not found
The first thing to check is find the absolute path of XYZ, for example /path/to/XYZ
Try to run with the absolute path /path/to/XYZ
If running with /path/to/XYZ gives -bash: /path/to/XYZ: Permission denied that means you have a problem with permissions on the file and/or directories:
You need read and exec permission on the file itself: sudo chmod +rx /path/to/XYZ
You need exec permission on all path elements leading up to the file: sudo chmod +x /path /path/to
After fixing permission issues, running with /path/to/XYZ should work
After fixing permission issues, if running with XYZ (without full path) still doesn't work, that means /path/to is not on your PATH. Fix with PATH=$PATH:/path/to
Note: the above sudo chmod commands give permissions (read and exec) to all users: owner + group + other. In the case of the OP (and in most common cases), this is perfectly fine.
In situations with more sophisticated permission setup, you might need to be more specific, and use g+rx instead of +rx.
(for the record)
If it works with sudo, and without sudo you get command not found, that means that meteor is on the PATH for root but not for your user. To make it work for your user, you need to find the path to meteor and add it to your user's PATH. For example:
Become root with sudo su -
Find the path of meteor, run command: which meteor
Logout from root (Control-D) to return to your user
Add the base directory to PATH, for example if earlier which meteor gave you /usr/local/bin/meteor, then do this: PATH=$PATH:/usr/local/bin
After this, it should work with your user. To make it "permanent", add the last step in your ~/.bashrc.
If this still doesn't work, then perhaps your user doesn't have the execute permission on the file. Fix that with this command:
sudo chmod +x /usr/local/bin/meteor
From your comments it also seems your user doesn't have permission on the /usr/local/bin directory itself. Fix that with this command:
sudo chmod +rx /usr/local/bin
Shouldn't need an admin account to run it, standard user account works fine. You can locate the meteor file by typing which meteor. It will tell you what file is being used to execute.
Try removing the .meteor folder in your home directory, something like rm -rf ~/.meteor and the script from the bin folder rm /usr/local/bin/meteor or rm 'which meteor' (speech marks there are the ones above ~)
And then reinstall meteor without sudo using the curl https://install.meteor.com/ | sh command.
Should hopefully install with all the correct permissions...
This might seem a little strange question at first but here me out.
I'm writing a shell script that makes up a file system that'll get compressed back into an archive and it needs some files in it to be owned by the root user. This whole thing is going to be automated soon but right now it's a bit of a problem because if I use sudo I need to enter in a password.
Seeing as the files are created beneath my own home directory for which I have full access I thought perhaps I can change their ownership to a root user. Is that possible?
If I try it normally I get "Operation not permitted". Maybe there is an alternative?
You can do what you want using fakeroot. It's a library that makes programs think they're running as root, when they are not. IIRC, it is used by dpkg to allow non-root users to build .deb packages that contain root-owned files.
Check out this shell script:
#!/bin/bash
mkdir image
touch image/user-owned
touch image/root-owned
chown renato.renato image/user-owned
chown root.root image/root-owned
tar cf image.tar image
Normally, I would only be able to create this tar archive as root. However, if I use fakeroot:
$ fakeroot ./create-image.sh
$ tar tvf image.tar
drwxr-xr-x root/root 0 2014-04-09 01:09 image/
-rw-r--r-- root/root 0 2014-04-09 01:09 image/root-owned
-rw-r--r-- renato/renato 0 2014-04-09 01:09 image/user-owned
However, the files on the disk are still user-owned, so no security risk here:
$ ls -l image/
total 0
-rw-r--r-- 1 renato renato 0 Abr 9 01:09 root-owned
-rw-r--r-- 1 renato renato 0 Abr 9 01:09 user-owned
When I try to change the permissions for a file it doesn't seem to work. chmod says it is changing it but the file permissions remain the same. Can anyone explain what I am doing wrong? Here is a copy of my command line.
~$ sudo chmod -v u+x ex01
mode of 'ex01' changed from 0600 (rw-------) to 0700 (rwx------)
~$ ls -l ex01
-rw------- 1 user user 60297 Feb 6 21:50 ex01
Certain file systems, such as vfat, don't support Unix permissions. The owners and permissions of the files are decided when the file system is mounted. On vfat for example there is an option to set the permissions to whatever you want, and another that sets the execute bit only for .exe, .com, .bat and similar files. See https://www.kernel.org/doc/Documentation/filesystems/vfat.txt