I have a setuid program (getpwd) that runs as expected only when owned by root.
-rwsr-xr-x 1 root root 7981 2011-11-17 18:28 getpwd*
In other words when my program is executed on the command line by user "alice" all works fine
The program opens a file in directory /home/secure and print the contents to screen.
alice#devbox:/home/alice/tmp$ ./getpwd
setuid is working
However when I change the ownership and set setuid of the file:
chown secure:users getpwd
chmod 4755 getpwd
-rwsr-xr-x 1 secure users 7981 2011-11-17 18:28 getpwd*
The program does not run when executed as user "alice".
alice#devbox:/home/alice/tmp$ ./getpwd
cannot open file /home/secure/test ...
Why is this happening?
ls -ld /home/ /home/secure/
drwx--x--x 2 secure users 280 Nov 18 11:16 /home/secure/
ls -ld /home/secure/*
-rw------- 1 secure users 33 Nov 15 14:35 /home/secure/test
How do I ensure that only user "alice" can run the setuid program owned by secure?
There are two possible approaches. One uses nothing but traditional Unix permissions and the other uses newfangled ACLs.
Traditional Unix
Create a new group; perhaps ALICE or something obviously different from an alice user account. Make sure alice is a member of ALICE in group(5). (vigr(8) is a great way to edit the group(5) file.) Set the ownership of your getpwd program secure:ALICE and remove world execute privileges on the file. Then, only secure and members of the ALICE group can execute the setuid getpwd program.
If alice is just a stand-in for a potentially larger group of people, then maybe name the group SECURE. (Upper case is just convenient for my description. You don't have to stick with upper case.)
Newfangled ACLs
setfacl -m u:alice:x getpwd
The setfacl(1) program is a bit complicated, but it allows you to create far more complex permissions than the traditional Unix permissions. Because these are pretty different, most systems I have seen don't have them turned on by default -- that requires the acl option to mount(8) when mounting the filesystem. You would need to add acl to the filesystems in /etc/fstab that need the extra permissions. (You don't need to reboot to make it available, though; mount /file/system -oremount,acl would be sufficient for as long as the filesystem is mounted -- typically until reboot.)
I suggest sticking with the traditional Unix method.
Related
I'm working on a git project that has a Dockerfile. When I run ls -l in the .git/objects repo, some of the "xx" directories are owned by me, with permissions 777, and some of the "xx" directories are owned by root, with permissions 755.
When I look into the directories owned by me, some or all of the hashed files will be owned by me with 777 permissions, and maybe some owned by root, with 444 permissions. When I look into the directories owned by root, all of the hashed files are owned by root with 444 permissions.
It seems that I might have run my container with root as container's user, which is why I get root as file owner in some parts of my repository.
I want to use Docker to help run and manage my code, but clearly the way I was using it was causing problems. Do I just need to run Docker as my normal user? If I ran all my git operations outside of the Dockerized terminal, that would probably avoid this as well, right? Or is there something else I can or should do?
Thanks for any and all feedback/advice
This is my jenkinx/jenkins_home/workspace folder looks like. (while doing ls -la)
drwxrwxrwx 24 nfsnobody nfsnobody 4096 Sep 29 18:26 workspace
There is a folder inside this workspace. This folder was created by Jenkins automatically when i build a job. This job name is Sandbox_Test-Job
Here's the folder
drwxr-xr-x 2 nfsnobody nfsnobody 4096 Sep 29 18:26 Sandbox_Test-Job
As you can see host machine's user does not have write permission to this folder and the script in the host machine is unable to write to Sandbox_Test-Vinod_M
I will have to manually set the permission first for this folder before the script can write. How can we make sure that when Jenkins create this job folder for each job, the folder has to have write permission for the user in the host?
First, you want to run ls -n to find the real UID/GID of the files/dirs instead of the display names. Next, check to see if that user appears in your /etc/passwd
nfsnobody:x:65534:65534:Anonymous NFS User:/var/lib/nfs:/sbin/nologin
You would need to find the displayed UID in ls -n, not nfsnobody - 65534.
It's unlikely "nfsbody is the owner of the files ( RHEL NFS reference , Linux Home Server HOWTO - Fedora ), more likely the files were written to an nfs volume shared across systems where the UID for jenkins ( run id jenkins) is not the same across them.
Align the UIDs (non-trivial as you must fix the passwd plus the existing ownership UID) and things will then be OK.
Suggested reading from SUSE and ServerFault.
If you're lucky - all the files have one UID and you just need to sync the UID in the passwds, or maybe blow them all away if it's just the workspaces.
ps: Not really a Jenkins issue, better guidance to be found on Serverfault or SuperUser.
pps: there is some help on S/O worth reading as well (search "nfsnobody'):
nfsnobody User Privileges, chown: invalid user: ‘nfsnobody’ in fedora 32 after install nfs
I want to add a new user to my debian server.
The user should have access rights to ruby / rails / rvm / gem / git / and folder /var/www/
How do I add this user correctly?
The user should be able start a webrick server and install gems.
A standard user should be able to do all that with a single-user installation of rvm.
Just follow the instructions on https://rvm.io
In order to check if your user has rights on /var/www :
check your user's groups :
groups #{username}
check permissions on /var/www :
ls -al /var | grep www
you should get something like :
drwxr-xr-x 15 www-data www-data 4096 #{timestamp} www
Let's review this character by character :
d is for directory (- for a regular file, l for links, etc...)
next 3 characters are the permissions for the owner of the file (rwx here, meaning full access r for reading, w for writing, x for executing)
next 3 define permisssions for the group which the file belongs to (r-x means that writing is disabled)
next 3 define permissions for any (other) user on the machine.
The 15 is the link count (how many links to this item). It varies between platforms.
first name (www-data) next is the owner of the file, for which rwx applies, then second www-data is the name of the group /var/www belongs to.
Finally, you get size and name of the file.
To solve your problem of accessing /var/www with your user, he will have to have at least r-- (and probably r-x) on the directory. This can be provided in two ways : add your user to the group that /var/www belongs to (use usermod -G #{groupname} #{username}) and make sure the group has the good rights (use chmod for that). Second way is to make your user the owner of /var/www (chown is your ally there).
Can you post the results of these commands in your question?
I'm using capistrano to deploy a rails web app. I want to give the deploy user on the webserver as few privileges as I can. I was able to do everything I need to do as a non-privileged user except restart the webserver.
I'm doing this on an ubuntu server, but this problem is not specific to my use case (rails, capistrano, deployment), and I've seen a lot of approaches to this problem that seem to involve poor security practices. Wondering whether others can vet my solution and advise whether it's secure?
First, not necessary, but I have no idea why /etc/init.d/nginx would need any (even read) access by other users. If they need to read it, make them become root (by sudo or other means), so I:
chmod 750 /etc/init.d/nginx
Since the ownership is owner root, group root (or can be set such with chown root:root /etc/init.d/nginx) only root, or a user properly sudo'ed, can read, change or run /etc/init.d/nginx, and I'm not going to give my deploy user any such broad rights. Instead, I'm only going to give the deploy user the specific sudo right to run the control script /etc/init.d/nginx. They will not be able to run an editor to edit it, because they will only have the ability to execute that script. That means that if a someone gets access to my box as the deploy user, they can restart and stop, etc, the nginx process, but they cannot do more, like change the script to do lots of other, evil things.
Specifically, I'm doing this:
visudo
visudo is a specific tool used to edit the sudoers file, and you have to have sudoer privileges to access it.
Using visudo, I add:
# Give deploy the right to control nginx
deploy ALL=NOPASSWD: /etc/init.d/nginx
Check the sudo man page, but as I understand this, the first column is the user being given the sudo rights, in this case, “deploy”. The ALL gives deploy access from all types of terminals/logins (for example, over ssh). The end, /etc/init.d/nginx, ONLY gives the deploy user root access to run /etc/init.d/nginx (and in this case, the NOPASSWD means without a password, which I need for an unattended deployment). The deploy user cannot edit the script to make it evil, they would need FULL sudo access to do that. In fact, no one can unless they have root access, in which case there's a bigger problem. (I tested that the user deploy could not edit the script after doing this, and so should you!)
What do you folks think? Does this work? Are there better ways to do this? My question is similar to this and this, but provides more explanation than I found there, sorry if it's too duplicative, if so, I'll delete it, though I'm also asking for different approaches.
The best practice is to use /etc/sudoers.d/myuser
The /etc/sudoers.d/ folder can contain multiple files that allow users to call stuff using sudo without being root.
The file usually contains a user and a list of commands that the user can run without having to specify a password. Such as
sudo service nginx restart
Note that we are running the command using sudo. Without the sudo the sudoers.d/myuser file will never be used.
An example of such a file is
myuser ALL=(ALL) NOPASSWD: /usr/sbin/service nginx start,/usr/sbin/service nginx stop,/usr/sbin/service nginx restart
This will allow the myuser user to call all start, stop and restart for the nginx service.
You could add another line with another service or continue to append them to the comma separated list, for more items to control.
Also make shure you have run the command below to secure things
chmod 0440 /etc/sudoers.d/myuser
This is also the way I start and stop services my own created upstart scripts that live in /etc/init
It can be worth checking that out if you want to be able to run your own services easily.
Instructions:
In all commands, replace myuser with the name of your user that you want to use to start, restart, and stop nginx without sudo.
Open sudoers file for your user:
$ sudo visudo -f /etc/sudoers.d/myuser
Editor will open. There you paste the following line:
$ myusername ALL=(ALL) NOPASSWD: /usr/sbin/service nginx start,/usr/sbin/service nginx stop,/usr/sbin/service nginx restart
Save by hitting ctrl+o. It will ask where you want to save, simply press enter to confirm the default. Then exit out of the editor with ctrl+x.
I'm trying to install Jenkins on a Tomcat 7 container.
When I try to open the Jenkins web app I get following error:
Unable to create the home directory '/home/myuser/jenkins/work'. This is most
likely a permission problem.
To change the home directory, use JENKINS_HOME environment variable or set
the JENKINS_HOME system property. See Container-specific documentation for
more details of how to do this.
Before starting Tomcat, I did chmod uog+rwx /home/myuser/jenkins. So, I suppose that Jenkins should be able to create a subdirectory there.
But obviously it can't.
How can I fix this problem?
Update 1:
lt -lt returns
drwxrwxrwx 2 root ec2-user 4096 Jun 23 10:25 jenkins
for /home/myuser/jenkins. /home/myuser/jenkins/work doesn't exist because Jenkins is supposed to create it.
Update 2: Just tried to create the work directory and to run chmod uog+rwx on it. It didn't help.
Update 3: Additional information:
I need Jenkins in order to
run lengthy tests in the night (fast unit tests are run before every mvn install, slow tests are executed every night) and
save software quality metrics (checkstyle, PMD, FindBugs, unit test coverage etc.) over time.
I have only one machine available for that and there is a Tomcat7 container installed there already.
At the moment, I don't want to invest additional money into buying new machines.
The machine with the Tomcat7 container (and where I want Jenkins to be installed) is an Amazon EC2 microinstance (OS version is given below).
$ cat /etc/*-release
LSB_VERSION=base-4.0-amd64:base-4.0-noarch:core-4.0-amd64:core-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch
Amazon Linux AMI release 2013.03
Update 4 (29.06.2013 13:34 MSK): The output of yum list does not contain any Jenkins/Hudson package.
If Tomcat is running as a separate user you will need to give execute permission to your home directory to that user - either by giving it to all or by creating a group especially for you and the tomcat user.
(UPDATE) More specifically: You say you already did chmod uog+rwx /home/myuser/jenkins, if Tomcat is not running asl 'myuser' it also needs execute permission on /home and on /home/myuser to be able to open /home/myuser/jenkins. If you are not picky about other users on the system opening your homedir you could allow this by: chmod a+x /home/myuser. (I'm assuming here the permissions for /home are already ok)
If you are running tomcat as 'myuser' the filsystem permissions look fine, but Tomcat's own permission system might be the problem as webapps are not allowed to touch the filesystem if the default settings of the security manager are on.
See: https://wiki.jenkins-ci.org/display/JENKINS/Tomcat
You don't specify more about your exact Tomcat/OS setup so I can't give exact details, but the fast way to find out if it's a security manager issue is to give AllPermission to you webapp. If you don't run in a safe environment it is advisable to only use that as a test, and setup only the really needed permissions later.
run these three commands
cd /usr/share/tomcat7
sudo mkdir .jenkins
sudo chown tomcat7:nogroup .jenkins
https://seleniumwithjavapython.wordpress.com/home/jenkins-installation/
It looks like the problem may be that jenkins cannot see /home/myuser, and therefore it cannot access the jenkins folder inside this (even though it has write permissions in /home/myuser/jenkins, I believe the fact it can't read /home/myuser causes a problem).
Try running the below command and then see if Jenkins works after that:
chmod +r /home/myuser
#robjohncox Yes - drwx------ 5 myuser myuser 4096 Jun 23 10:25 myuser
you must add +x to this dir to make it possible for jenkins to access it's contents, to be precise whole path has to have +x enabled for everyone.
Also, what commands have you used to move it's home dir from default - possible error is somwhere there. Cheers, Piotr