Linux - ServerThis forum is for the discussion of Linux Software used in a server related context.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I have a group of dev team that keep asking me to be added to sudo users.
I do not want to do it because it is fat too much they need.
They all belong to a (tomcat) group and can do all of they need but when they need to start the application they script if calling sudo and tomcat user.
sudo -u tomcat /and the rest path to start it.
So when they execute the command they are propped about users password that is not in a sudo users group.
The access list does not resolve the issue in this case I suppose.
Could you advise what would be the best way to avoid it?
Not sure if I get this correctly but if your devs "dont listen", you could just override sudo by editing their PATH and replacing sudo with a command that simply discards all arguments and does nothing, but just execute the actual command.
If you cared to peruse sudoers man page, you would've learned that sudo is not a 'gimme root' but fully granular control tools and lets one specify which user may run which command with which credentials.
If you cared to peruse sudoers man page, you would've learned that sudo is not a 'gimme root' but fully granular control tools and lets one specify which user may run which command with which credentials.
I would recommend Michael W Lucas' book, sudo Mastery, to take a deep dive into the capabilities of sudo as a tool for providing granular access. While the book is on order from your college library or via your local bookstore you can hunt down the video of his talk, "sudo: You're Doing It Wrong", to get a rather quick overview of the tool.
Then keep checking the manual page, using the command "man sudoers", as you go through the book. It is one of the more daunting manual pages out there, but is the ultimate reference (besides the source code) as to what the utility can do for you.
with other words: with sudo you can allow start/stop (or any other script) script to run only, nothing else. You just need to take care of that script (so nobody should be able to modify it).
sudo is not a 'gimme root' but fully granular control tools and lets one specify which user may run which command with which credentials.
I agree with that and think that Canonical/Ubuntu bear a lot of responsibility for the abuse. The ubuntu.com site at the link below gives Advantages and Disadvantages of always using sudo and reading through the Advantages they are pretty silly reasons and seem to be pandering to the lazy. Number 8 on that list is what sudo is supposed to be used for.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.