4

Based on following thread, I am trying to send a job under another user.

I am logged in as the main_user, and slurm jobs are submit via main_user that can do rm -rf /home/main_user that is pretty dangerous.

In order to prevent this I want to run a job under another user's permission under the main_user's directory. I think that if I am able managed to submit the job through newly created user, that user has no permission to alter into any of my files, expect the folder that the user is running his job.

Creating a new user:

sudo useradd -m newuser -d /home/newuser
sacctmgr add account newuser --immediate
sacctmgr create user newuser  defaultaccount=newuser adminlevel=[None] --immediate

Approach 1: Running as newUser under main_user's directory:

$ cd pathToRunMyJob
$ sudo chown -R newuser:newuser .
$ id -u newuser
1004
$ sbatch  --uid=1004 run.sh

Approach 2: running job inside newly created user's folder under home directory:

$ cd /home/newuser
$ id -u newuser
1004
$ sbatch --uid=1004 run.sh

But now I am having following pending message:

JOBID PARTITION   NAME     USER ST       TIME  NODES NODELIST(REASON)
  602     debug   run.sh   deneme PD     0:00      1 (launch failed requeued held)

Update:

I have tried to submit a job under another user via using @Dmitri Chubarov' comment:

sudo su - newuser ; sbatch run.sh

That seems like solution. After I did sudo su - newuser then sbatch run.sh , it prevents newuser 's source code to change other users' folders.

Also, I just want to prevent a user not to access any important data stored by any other user. chmod go-rwx /home/* or chmod 700 ~/* makes other users' folder unaccessible; could it be a helpful solution?

alper
  • 2,919
  • 9
  • 53
  • 102
  • 2
    Can you submit a job as a `newuser` directly, e.g. `sudo su - newuser ; sbatch run.sh`? – Dima Chubarov May 10 '18 at 14:23
  • It seems like working, I can submit the job into slurm and cannot delete `main_user` s files and create file on its directory. But after I have done `sudo su - newuser`, `newuser` can do `ls /home/main_user` and see `main_user` 's files also can read them, is there any way to prevent `newuser` to read other users' files? @Dmitri Chubarov – alper May 10 '18 at 18:03
  • One option you have is to set up permissions to block group and world from reading the files, i.e. set `main_user`'s `umask` to `0077` and take away world and group read and execute permissions from existing `main_users`'s files with `chmod`. However be aware of the effect strict `umask` would have for instance on your `sudo` commands. – Dima Chubarov May 11 '18 at 09:59
  • I have tried: `sudo chmod 0750 /home/` but now when I try to do `sudo su -newuser`it gives: `No directory, logging in with HOME=/` error. @DmitriChubarov – alper May 11 '18 at 10:21
  • `/home` is owned by the `root` user and it's mode must be 0755 (otherwise no user would be able to access their own home directories as they are not in the same group as `root`). Also you need to run `chmod` in recursive mode to relabel all files in the directory. Sorry this seems to digress from the original question. – Dima Chubarov May 11 '18 at 12:31
  • I have also tried jail user from this link (https://askubuntu.com/a/102206/660555) but this can still see the other users' files on the home directory. I guess my only option is to do your first suggestion. @Dmitri Chubarov – alper May 11 '18 at 12:37
  • At least I can prevent `newuser` to access /home/* directories using `chmod go-rwx /home/*`. but user can see `/var /tmp` etc. Do you think this will help? I can ask a new question about this topic, since its digress from the original question. @DmitriChubarov – alper May 11 '18 at 15:06

2 Answers2

4

But after I do sbatch run.sh , I get following message: Submitted batch job *** ; but submitted job does not show up on squeue and the job does not launch on Slurm.

Often, that indicates that newuser is not known on the compute node. you have to run the useradd command on all compute nodes as well. But that should be clear from the Slurm log filles.

Also, I just want to prevent a user not to access any important data stored by any other user. chmod go-rwx /home/* or chmod 700 ~/* makes other users' folder unaccessible; could it be a helpful solution?

Yes, chmod go-rwx /home/* would be the way to go.

damienfrancois
  • 52,978
  • 9
  • 96
  • 110
  • How about doing: First `chmod 700 /home/*`, then apply following for each created user, example: `setfacl -R -m user:newuser:rwx /home/newuser` and `setfacl -R -m user:slumUser:rwx /home/newuser` ? `slumUser` is a root user that will put source file into newuser's directory. After I did those, following command seems like solved it (`newuser` 's source code will not change other users' home folders and also cannot see them ): `sudo su - newuser ; sbatch run.sh` @damienfrancois – alper Jun 06 '18 at 10:34
  • Yes that can work, beware that ACL's do not necessarily work on all filesystems, especially network or parallel filesystems. Also, if the users only need to do limited actions like specify parameters and submit job, and not upload files, or modify files, compile soft, etc. you could setup a web interface and prevent SSH access at all – damienfrancois Jun 06 '18 at 10:44
  • I will keep ACL's in mind. It seems like it works with a simple front-end, compute-end setup. Is there any other alternative for the filesystems that if ACL do not work? When I create the users' I didn't create password for them, I guess their SSH access is close by default. => I got it so you are saying: User can only provide parameters and maybe share github link of the source code via web interface. Later, the slurmUser can download the code and handle the rest, ? But the issue is their source code may access other users' file if they embedded a code as: `cat /home/*/*` @damienfrancois – alper Jun 06 '18 at 10:56
  • of course if they can change what is executed, you need to compartmentalised, I was thinking of applications where the code does not change, and only input files can be provided, with no part executable at all – damienfrancois Jun 06 '18 at 11:00
  • Got it: it executable code is provided `chmod go-rwx /home/*` will at least prevent the user's source code (untested) to modify and read other users' home directories. @damienfrancois – alper Jun 06 '18 at 11:04
  • Is there any difference between `chmod go-rwx` and `chmod 700` ? @damienfrancois – alper Jun 07 '18 at 07:56
  • the former only alters permission for `other` while the latter sets permissions for all of `user`, `group` and `other` – damienfrancois Jun 07 '18 at 08:14
0

I have combined @damienfrancois and @Dmitri Chubarov's answers:

The way I created new user:

user.sh

#!/bin/bash

NEWUSER ="user"
BASEDIR="/var/users/"

sudo useradd -d $BASEDIR/$NEWUSER -m $NEWUSER
sudo mkdir -p $BASEDIR/$NEWUSER/cache
echo $USERADDRESS / $NEWUSER 'is added as user.'
      
sudo chmod 700 $BASEDIR/$NEWUSER # Block others and people in the same group to do read/write/execute
sudo setfacl -R -m user:$NEWUSER:rwx   $BASEDIR/$NEWUSER #Give Read/Write/Execute access to USER on the give folder.
sudo setfacl -R -m user:$SLURMUSER:rwx $BASEDIR/$NEWUSER #Give Read/Write/Execute access to root_slurmuser on the give folder.
    
# Add user to Slurm
sacctmgr add account $NEWUSER --immediate
sacctmgr create user $NEWUSER defaultaccount=$NEWUSER adminlevel=[None] --immediate

Later I have applied the @Dmitri Chubarov's recommendation:

Can you submit a job as a newuser directly, e.g. sudo su - newuser ; sbatch run.sh?

I have submitted job as the $NEWUSER

$ sudo su - $NEWUSER -c "cd $BASEDIR/USERADDRESS_home/path_to_run && 
sbatch -c2 slurmScript.sh
alper
  • 2,919
  • 9
  • 53
  • 102