Ticket 16236

Summary:	How to elevate a user for restricted semi-admin permissions
Product:	Slurm	Reporter:	Wei Feinstein <wfeinstein>
Component:	Other	Assignee:	Ben Roberts <ben>
Status:	RESOLVED INFOGIVEN	QA Contact:
Severity:	4 - Minor Issue
Priority:	---
Version:	22.05.6
Hardware:	Linux
OS:	Linux
Site:	LBNL - Lawrence Berkeley National Laboratory	Alineos Sites:	---
Atos/Eviden Sites:	---	Confidential Site:	---
Coreweave sites:	---	Cray Sites:	---
DS9 clusters:	---	HPCnow Sites:	---
HPE Sites:	---	IBM Sites:	---
NOAA SIte:	---	OCF Sites:	---
Recursion Pharma Sites:	---	SFW Sites:	---
SNIC sites:	---	Linux Distro:	---
Machine Name:		CLE Version:
Version Fixed:		Target Release:	---
DevPrio:	---	Emory-Cloud Sites:	---

Description Wei Feinstein 2023-03-09 18:29:25 MST

Dear support team,

I wonder how to elevate the role of a user from a slurm account,  so that this special user can manage/cancel jobs belong to other users within the account group. 

I read about AdminLevel about assigning individual user different roles, such as Operator and etc, but not clear enough for me how to config. The bottomline has to be able to constrain the elevated admin function within his/her own account group.

Thank you,
Wei

Comment 1 Ben Roberts 2023-03-10 12:29:07 MST

Hi Wei,

It sounds like configuring a user as a coordinator for an account should do what you want.  This will allow the coordinator to have special privileges for the account they are coordinator over, but won't grant them any special privileges anywhere else.  Here's an example where I make 'user1' a coordinator over the 'sub1' account.

$ sacctmgr add coordinator account=sub1 user=user1
 Adding Coordinator User(s)
  user1
 To Account(s) and all sub-accounts
  sub1
Would you like to commit changes? (You have 30 seconds to decide)
(N/y): y


$ sacctmgr show user user1 withcoord
      User   Def Acct  Def WCKey     Admin       Coord Accounts 
---------- ---------- ---------- --------- -------------------- 
     user1       sub1                 None                 sub1 




To demonstrate how this works, I submit two jobs as 'user2', one to the 'sub1' account and the other to the 'sub2' account.

user2@kitt:~$ sbatch -n24 -Asub1 --wrap='srun sleep 600'
Submitted batch job 9993
user2@kitt:~$ sbatch -n24 -Asub2 --wrap='srun sleep 600'
Submitted batch job 9994


Then as 'user1' when I run squeue I can only see the job that is in the 'sub1' account.  When I try to delete the job in the 'sub2' account it rejects the request.  It does, however, let me delete the job in the 'sub1' account.

user1@kitt:~$ squeue
             JOBID PARTITION     NAME     USER ST       TIME  NODES NODELIST(REASON)
              9993     debug     wrap    user2  R       0:18      1 node10
user1@kitt:~$ scancel 9994
scancel: error: Kill job error on job id 9994: Access/permission denied
user1@kitt:~$ scancel 9993
user1@kitt:~$ squeue
             JOBID PARTITION     NAME     USER ST       TIME  NODES NODELIST(REASON)
              9993     debug     wrap    user2 CG       0:34      1 node10


Let me know if this doesn't look like what you were hoping, or if you have any questions about it.

Thanks,
Ben

Comment 2 Wei Feinstein 2023-03-12 19:21:37 MDT

Hi Ben,

Yes, the solution you provided is exactly what I am looking for. It works
perfectly!

Many thanks,
Wei

On Fri, Mar 10, 2023 at 11:29 AM <bugs@schedmd.com> wrote:

> *Comment # 1 <https://bugs.schedmd.com/show_bug.cgi?id=16236#c1> on bug
> 16236 <https://bugs.schedmd.com/show_bug.cgi?id=16236> from Ben Roberts
> <ben@schedmd.com> *
>
> Hi Wei,
>
> It sounds like configuring a user as a coordinator for an account should do
> what you want.  This will allow the coordinator to have special privileges for
> the account they are coordinator over, but won't grant them any special
> privileges anywhere else.  Here's an example where I make 'user1' a coordinator
> over the 'sub1' account.
>
> $ sacctmgr add coordinator account=sub1 user=user1
>  Adding Coordinator User(s)
>   user1
>  To Account(s) and all sub-accounts
>   sub1
> Would you like to commit changes? (You have 30 seconds to decide)
> (N/y): y
>
>
> $ sacctmgr show user user1 withcoord
>       User   Def Acct  Def WCKey     Admin       Coord Accounts
> ---------- ---------- ---------- --------- --------------------
>      user1       sub1                 None                 sub1
>
>
>
>
> To demonstrate how this works, I submit two jobs as 'user2', one to the 'sub1'
> account and the other to the 'sub2' account.
>
> user2@kitt:~$ sbatch -n24 -Asub1 --wrap='srun sleep 600'
> Submitted batch job 9993
> user2@kitt:~$ sbatch -n24 -Asub2 --wrap='srun sleep 600'
> Submitted batch job 9994
>
>
> Then as 'user1' when I run squeue I can only see the job that is in the 'sub1'
> account.  When I try to delete the job in the 'sub2' account it rejects the
> request.  It does, however, let me delete the job in the 'sub1' account.
>
> user1@kitt:~$ squeue
>              JOBID PARTITION     NAME     USER ST       TIME  NODES
> NODELIST(REASON)
>               9993     debug     wrap    user2  R       0:18      1 node10
> user1@kitt:~$ scancel 9994
> scancel: error: Kill job error on job id 9994: Access/permission denied
> user1@kitt:~$ scancel 9993
> user1@kitt:~$ squeue
>              JOBID PARTITION     NAME     USER ST       TIME  NODES
> NODELIST(REASON)
>               9993     debug     wrap    user2 CG       0:34      1 node10
>
>
> Let me know if this doesn't look like what you were hoping, or if you have any
> questions about it.
>
> Thanks,
> Ben
>
> ------------------------------
> You are receiving this mail because:
>
>    - You reported the bug.
>
>

Comment 3 Ben Roberts 2023-03-13 08:28:16 MDT

I'm glad to hear that works for you.  I'll go ahead and close this ticket.

Thanks,
Ben