I have a program that I need to run with sudo. I create a directory using mkdir, but this directory has owner and group set to root. That makes sense since I am using sudo. I would like to change the owner and group to the normal user, but I'm not sure how to do that. I thought running system("chown $USER:$USER /directory/") would work, but I suppose since I am in sudo it will just set to root. I was looking into using chown, but I wasn't sure how I was supposed to get the owner and group id. Also it would be good for it to be portable, so I don't want to just hardcode a user/group id.
You're mostly on the right path already, chown is the command you're looking for here.
You can string the two commands to make and then own the directory together using a semicolon.
sudo mkdir test ; sudo chown $USER:$USER test
I've tested this on ubuntu 18.04 and ubuntu 20.04 as that's your tag. The $USER variable resolves to the user that you originally logged in as, not root, as long as you're using it at the beginning of your command like the above. Note that you need to call sudo again when doing the chown portion, the ; ends the sudo elevation.
The coreutils package includes an useful little command, install, you can use instead of mkdir in a sudo context. For example,
sudo install -o USER -g GROUP -m MODE -d DIRECTORY
where USER is the user to own the directory DIRECTORY, GROUP is the group to own the directory, and MODE is the access mode (like chmod) to the directory.
Because system(COMMAND) and popen(COMMAND,...) actually run /bin/sh with -c and COMMAND as parameters, you can use the form
sudo install -o $(id -u) -g $(id -g) -m u=rwx,g=r-x,o=x DIRECTORY
where the shell replaces the user and group names (or rather, numbers, since I'm not using the -n option) before executing sudo. (The id command is also included in coreutils, so you can definitely expect both install and id to be available on all full-blown Linux machines; and even on most embedded systems. It is what all package managers et cetera use to install files, you see.)
Above, I used the mode u=rwx,g=r-x,o=x (equivalently, 0751) as an example; it sets the mode to rwxr-x--x, i.e. grants access to everybody, with owner user and group being able to list the directory contents, and only the owner user being able to create new files or directories in it.
Related
I have a working Centos/Plesk (18.0.40 Update #1) environment running Plesk-Scheduled-Tasks with no problems, and I have a new machine that should be a duplicate of that machine (Plesk 18.0.42 Update #1) that is failing to run the Plesk-Scheduled-Tasks (reporting "No such file or directory" on all the tasks that I have added).
Eliminating as many permissions factors as possible, I am testing a scriptless task running "whoami" will work on the original machine but shows an "-: whoami: command not found" error message on the new.
Note, I am also declaring tasks at the domain level - if I was to add a top level task (where it prompts you for the System user) then it can use root and therefore works - but I do not want these tasks to run under root.
Clicking "Run Now" gives the following:
Hiho.
The run scheduled tasks and also the shell access if it´s enabled for your subscription is mostly chrooted. So you have only a minimum on commands which you can use here.
If you open your subscription via FTP Client you should see a bin folder in there. In the bin folder are all commands you are able to use in the chrooted shell.
Example on one of my subscriptions:
bash cat chmod cp curl du false grep groups gunzip gzip head id less ln ls
mkdir more mv pwd rm rmdir scp sh tail tar touch true unrar unzip vi wget
I'm currently in the process of switching from an Ubuntu 18.04 VirtualBox to the WSL.
Everything is up and running to have a complete web dev environment.
Unfortunately, the file permission and ownership is kind of a problem for me right now.
--- Disclaimer---
I know that in a server environment this would be pretty bad and wouldn't be done.
This is just for my local development process and this requirement will stay there.
What I want to achieve is, to have a consistent set of permissions and ownerships within my /var/www (and all below).
Every element within /var/www should be owned by my shell user, regardless if file or dir.
Every element should have the group www-dataso that the webserver user have access.
Each file should have permission 0664 and each directory 0775.
every new element should follow these requirements.
What I researched so far:
If I make a new directory/ file from the shell or within VSCode, my user and group are used.
If I make a new directory from the windows explorer, the ownership is root:root. Nevertheless, I also have to figure out how to set default permissions for new objects.
I just want an easy to use way to CRUD my files from anywhere I am on my system.
Is there anyone with an idea for this?
Thanks a lot, Danaq.
Edit: It would also be ok, to set everything to www-data:ww-data and add my shell user to the www-data-group if the permissions are applied like explained above.
According to this, newer versions of the Remote-WSL server, when they get started will execute (if present):
~/.vscode-server/server-env-setup
~/.vscode-server-insiders/server-env-setup
(more on that)
So a solution is to execute:
# this will affect folders created from the editor
mkdir -p ~/.vscode-server/ && echo "umask 002" >> ~/.vscode-server/server-env-setup
mkdir -p ~/.vscode-server-insiders/ && echo "umask 002" >> ~/.vscode-server-insiders/server-env-setup
# this will affect folders created from terminals
echo "umask 002" >> ~/.bashrc
For everyone encountering the same issue and find this question:
Under ~[USER~/.profile I uncommented the umask-property and set it to 002.
This will, according to this guide, set all new created file to 0664 and all new directories to 0775.
I then added the www-data-user to the group of my shell-user with
sudo usermod -a -G www-data [GROUP].
So now, every file I'm creating is owned by and within the group of my shell user. But it can be red by the www-data-user too. This should lead to not always using the
find ./ -type d -exec chmod 775 {} \;
the command to set the right permissions on all directories of a web project after migration for example.
This solution does only help, if the files and directories are created from the WSL-bash. If you are using the explorer or trying to create a file from the VSCode-terminal, the default umask of 022 will be still applied.
I'm trying to disable randomization via Dockerfile:
RUN sudo echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
but I get
Step 9 : RUN sudo echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
---> Running in 0f69e9ac1b6e
[91mtee: /proc/sys/kernel/randomize_va_space: Read-only file system
any way to work around this? (I see its saying read-only file system any way to get around this?) If its something which the kernel does this means it's outside of my container scope, in that case how am i supposed to work with gdb inside my container? please note this is my target to work with gdb in a container because i'm experimenting with it, so i wanted a container which encapsulates gcc and gdb which i'll use for experimentations.
In host
run:
sudo echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
not in docker
Docker has syntax for modifying some of the sysctls (not via dockerfile though) and kernel.randomize_va_space does not seem to be one of them.
Since you've said you're interested in running gcc/gdb you could disable ASLR only for these binaries with:
setarch `uname -m` -R /path/to/gcc/gdb
Also see other answers in this question.
Sounds like you are building a container for development on your own computer. Unlike production environment, you could (and probably should) opt for a privileged container. In a privileged container sysfs is mounted read-write, so you can control kernel parameters as you would on the host. This is an example of Amazon Linux container I use to develop for on my Debian desktop, which shows the difference
$ docker run --rm -it amazonlinux
bash-4.2# grep ^sysfs /etc/mtab
sysfs /sys sysfs ro,nosuid,nodev,noexec,relatime 0 0
bash-4.2# exit
$ docker run --rm -it --privileged amazonlinux
bash-4.2# grep ^sysfs /etc/mtab
sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
bash-4.2# exit
$
Notice ro mount in the unprivileged, rw in the privileged case.
Note that the Dockerfile command
RUN sudo echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
makes no sense. It will be executed (a) during container build time (b) on the machine where you build the image. You want (a) happen at container's run time and (b) on the machine where you run the container. If you need to change sysctls on image start, write a script which does all the setup and then drops you into the interactive shell, like placing a script into e.g. /root and setting it as the ENTRYPOINT
#!/bin/sh
sudo sysctl kernel.randomize_va_space=0
exec /bin/bash -l
(Assuming you mount host working directory into /home/jas that's a good practice, as bash will read your startup files etc).
You need to make sure you have the same UID and GID inside the container, and can do sudo. How you enable sudo depends on a distro. In Debian, members of the sudo group have unrestricted sudo access, while on Amazon Linux (and, IIRC, other RedHat-like system, the group wheel has. Usually this boils down to an unwieldy run command that you rather want to script than type, like
docker run -it -v $HOME:$HOME -w $HOME -u $(id -u):$(id -g) --group-add wheel amazonlinux-devenv
Since your primary UID and GID match the host, files in mounted host directories won't end up owned by root. An alternative is create a bona fide user for yourself during image build (i.e., in the Dockerfile), but I find this more error-prone, because I can end up running this devenv image where my username has a different UID, and that will cause problems. The use of id(1) in a startup command guarantees UID match.
I have compiled a c program into an executable that I would now like to integrate into the applications menu in Debian 7.4 XFCE. In order to run the application under normal circumstances, I am required to type
sudo myprogram
Now I have created my .desktop file and placed it in /usr/share/applications
[Desktop Entry]
Type=Application
Encoding=UTF-8
Name=myprogram
Comment=configuration loader
Exec=sudo loader
Icon=/usr/share/icons/hicolor/48x48/apps/myprogram.png
Terminal=false
Categories=Development;IDE
The item is added to my applications menu as expected, and the icon shows up properly. The problem, however, is that double clicking the menu item to launch the application does nothing.
If I navigate to /usr/bin (where I have placed my executable) and type "sudo myprogram", the program launches as expected.
What can I do to fix this issue and get the program to launch from the menu? Perhaps /usr/bin is not the correct place to put it, or I have the incorrect Exec command. I greatly appreciate the help.
I ended up using (after installing gksu)
Exec = gksu myprogram
this launches a graphical sudo prompt, which is sufficient for my needs.
This is what the setuid bit in the permissions is for. It makes executables run with permissions of the file owner. This only works on actual executables, not on shell scripts!
sudo chmod u+s myprogram
sudo chown root myprogram
./myprogram # now runs as root
Please be careful when using this as it will always execute that program as root no matter who executes it. You can limit access by setting it to your usergroup and deny all execute.
chgrp "${USER}" myprogram # provided you have individual groups set up
chmod a-x myprogram # deny all execute
This approach does not need additional installation of packages.
Terminal=true opens a new terminal window which runs
sudo -i to ask for the password.
Then, using sh to run the program, the Terminal is closed and myprogram runs in the background because it has a & at the end.
[Desktop Entry]
Type=Application
Name=...
Exec=sudo -i sh -c "myprogram &"
Terminal=true
Request: Please report if it works under your OS.
Tested under:
Xubuntu
The pkexec solution from askubuntu:
Exec=pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY APP_COMMAND
Try adding this to .desktop
Path=/path/to/myprogram
I would like to know the answers and explanation to the following questions:
Which user/group should own the cake files?
If different, which user/group should own the app/tmp folder? (and subfolders)
With the right user/group, what are the correct permissions for production of both folders and files? (which also if set correctly should work on development)
Where is storing of uploaded files done and what ownership/permissions need to be set to that folder. Where should it be relative to app/?
I know 777 fixes errors, but I would like to set it up correctly.
I have heard 660 should be more than enough for production if everything is correctly set up.
Who needs to have read access, who needs to have write access and does anyone need execute?
NOTE: I think I have found the answers and since no one has written a good answer, I will write it.If you are more knowledgeable on the topic and see errors or security issues please let me know, I will correct them.
1) CakePHP ownership
The CakePHP files should be owned by you, the user of the machine (whatever you log in with). Do not have root as owner!
OSX: the johnsmith part of /Users/johnsmith
Linux: the johnsmith part of /home/johnsmith
2) app/tmp ownership.
As per CakePHP documentation:
...make sure the directory app/tmp and all its subdirectories in your
cake installation are writable by the web server user.
Option 1:
The user owner needs to be apache's user. The group owner can be the group that you belong to, so that you also have access to this folder through finder/CLI. Do not have root as owner!
OSX: Apache is preinstalled on OSX lately and the default user of apache is _www. However if you are not sure you can find it out by typing terminal ps aux | grep httpd while apache runs. The last line is the command you just typed, so look above it.
Now that you know your apache user, you have to assign it to app/tmp/. You do this with the following command: sudo chown -R _www app/tmp/
Linux: The default user on linux is usually www-data with group www-data. If you are not sure, use ps aux | grep httpd to find out the user and sudo chown -R _www app/tmp/ to assign ownership to apache of that folder.
Option 2:
You can keep yourself as the user owner, but you set up the group owner to be the a group that apache belongs to. By default apache has it's own group, but you could create a new group and add apache to it.
OSX: The group of apache on OSX by default is the same os the user: _www. You then have to run the following command to se up the ownership: sudo chown -R :_www app/tmp/. Now if you check the permissions with ls -l you should see both your username (johnsmith) and the new group owner - _www.
Linux:* By default the group of apache is www-data so use the same commands to change ownership: sudo chown -R :www-data app/tmp/.
NOTE: Debian/Ubuntu use www-data, while CentOS uses apache.
3) Permissions
For the site to run, apache needs read and write without execute. For you to access it (assuming you are in the group that owns app/tmp) you also need read and write if you will edit manually things with terminal/finder. All other users should have no rights whatsoever. So:
OSX&Linux: sudo chmod -R 660 app/tmp/. The -R part is to do it recursively for all inside folders. The first 6 is for the user owner (OSX:_www or Linux:www-data), the second 6 is for the group owner (OSX:staff or Linux: johnsmith), the 0 is for all other users/guests.
NOTE: According to this pull request for CakePHP it looks like CakePHP 2.4 will have ability to create subfolders in app/tmp/ which means it will need a 7 instead of 6 for the user now becoming 760.
4) Uploads folder
If you want to upload files, you need a similar setup for the img/uploads folder, or wherever you upload. The ownership will be the same, but the permissions need to have execute rights for renaming purposes and folder creation. so the previously 660 should now be 760. Also, ideally, the uploads are out of the webroot/ directory, for which an absolute path is required.
For all files in app/tmp and subfolders you only need rw for the web server process and if needed to use the CLI, the console user.
If someone runs console commands with a user that has super rights or is in the wrong group it messes up things because what one creates can't be read or written from the other and then there are warning or failure messages. Some people (including me when I'm too lazy) fix that with 777 :)