Bugzilla – Bug 773
Resolution of Runas syntax
Last modified: 2017-12-31 17:50:07 MST
I'm using Ubuntu Linux on a VM. I have the following policy in sudoers: oeusr1 ALL=(root:oedbadm) EXEC: /usr/dlc/bin/* Using the above, I can run commands out of /usr/dlc/bin as either root or as a member of oedbadm. But, I want user "oeusr1" to have the choice of running commands out of /usr/dlc/bin as either the "root" user of as a member of the "oedbadm" group. I want to replace the Runas selections with a Runas alias for reuse but I can't get this to work. "Runas_Alias root:oedbadm" is a syntactical error condition. "Runas_Alisa AUTH_OE_ADMIN = root,%oedbadm" "oeusr1 ALL=(AUTH_OE_ADMIN) EXEC: /usr/dlc/bin/*" Is syntactically correct but "sudo -g oedbadm /usr/dlc/bin/_progres ..." fails with "oeusr is not allowed to execute /usr/dlc/bin/_progres ..." NOTE: sudo -u root /usr/dlc/bin/_progres ..." works fine Tried reversing the order but that didn't help: "Runas_Alias AUTH_OE_ADMIN = root,%oedbadm" It appears that Runas does not preprocess the Runas alias to sort users from groups and present the users and groups in the colon-divided format "(users:groups)" that runas processing appears to need.
A Runas_Alias cannot contain a user:group pair. You will need a separate Runas_Alias for the user and group portions. The following should do what you want: Runas_Alisa AUTH_OE_ADMIN_U = root Runas_Alisa AUTH_OE_ADMIN_G = oedbadm oeusr1 ALL=(AUTH_OE_ADMIN_U:AUTH_OE_ADMIN_G) EXEC: /usr/dlc/bin/* Note that you need "oedbadm" and not "%oedbadm". If you use something like: oeusr1 ALL=(%oedbadm) EXEC: /usr/dlc/bin/* it will allow oeusr1 to run commands as any user who is a member of the oedbadm group which is not what you intend. Does that help?
Thank you Todd. Yes, that helped. I would have thought visudo was going to complain if I specified a group without a % prefix. Nice to know this is doable. Not sure it makes sense to allow exceptions to the rule for Runas_Aliases. Why not pre-process a regular, conforming Alias into the user:group format when a regular, conforming alias is placed into the runas parens. And, just pass through the hard coded value if the user:group format is used. Seems like that's a little more consistent but versatile. Anyway, I'm happy with the workaround. Thanks again.
Actually, scratch the earlier comments ... I just got around to testing the workaround and it doesn't work. # User alias specifications User_Alias OEUSER = %oeuser User_Alias OEUSERS = oeadm1, oesecadm1, OEUSER Host_Alias PROD_DBSRVRS = dbsrvr1, dbsrvr2, dbsrvr3, dbsrvr4 Runas_Alias AUTH_DBA_U = root Runas_Alias AUTH_DBA_G = oedbadm # Command specifications Cmnd_Alias OEEXE = /oe117/dlc/bin/_progres # Policy OEUSERS PROD_OESRVRS = (AUTH_DBA_U:AUTH_DBA_G) OEEXE Now run sudo with the above policy: sudo -u root /oe117/dlc/bin/_progres -- This one succeeds. sudo -g oedbadm /oe117/dlc/bin/_progres -- Gets, "Sorry, user fails with "oeusr1 is not allowed to execute ..." NOTE: This is the same result as I get if I try to put a normal Runas_alias together and place that into the policy: Runas_Alias AUTH_DBA root,%oedbadm OEUSERS PROD_OESRVRS = (AUTH_DBA) OEEXE try to run with "sudo -u root /oe117/dlc/bin/_progres", this works! try to run with "sudo -g oedbadm /oe117/dlc/bin/_progres", gets, "Sorry, user oeusr1 is not allowed to execute ..." When I change the runas syntax of the policy to the (user:group) format, i.e., "root,oedbadm), now both work: sudo -u root /oe117/dlc/bin_progres -- this works sudo -g oedbadm /oe117/dlc/bin/_progres -- this also now works.
Hi Todd, Sorry for the misinformation ... I forgot to add the correction production machine to the host alias. Once I did that your workaround using an alias format conforming to (user:group) worked !!! Very sorry if I took any of your time looking at that. David
FYI - seems like a minor bug, so I'll just attach the condition to this one ... I accidentally missed an "n" in my command alias and visudo didn't fail the syntax check: Cmd_Alias OEEXE = /usr/dlc/bin/_progres versus Cmnd_Alias OEEXE = /usr/dlc/bin/_progres visudo accepts both but only thinks the latter is valid as far as setting policy.
This is a case where sudoers syntax is ambiguous. The line: Cmd_Alias OEEXE = /usr/dlc/bin/_progres gets parsed as a user named "Cmd_Alias" allowed to run /usr/dlc/bin/_progres on a host in the Host_Alias OEEXE. You should get a warning like the following from visudo: Host_Alias "OEEXE" referenced but not defined
Thanks Todd. Can't we say the same about any alias name misspelling that doesn't give clues like the % sign For instance, when I specify "RunasS_Alias", visudo throws a syntax error. But cant this: RunasS_Alias OEUSER = myuser be interpreted as: User "RunasS_Alias" is allowed to run "myuser" command from the OEUSER host?