Hi James,
Yes I tried to do this on another machine unfortunately this didn't work for me, good you raised this topic
On the other machine I edited the visudo
User_Alias PROJECT = emma, paddy, sb
PROJECT ALL = !/usr/su, !/bin/su, !/usr/bin/passwd
And then did this
paddy, emma, %PROJECT, %sys ALL = NETWORKING, SOFTWARE, SERVICES, STORAGE, DELEGATING, PROCESSES, LOCATE, DRIVERS
But no success neither paddy nor emma could install software using yum could they run any network commands :-(
I am sure I am doing something wrong try to google but no luck :-(
--
Harry
________________________________
From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of James Corteciano Sent: Friday, 27 June 2008 2:59 PM To: CentOS mailing list Subject: Re: [CentOS] Wheel and YUM!!
Hi Harry,
Try to implement sudoers and add the group "wheel" inside from it (you can modify it from /etc/sudoers or using visudo command). In that way, all your users can use yum command.
Cheers, -james
On Fri, Jun 27, 2008 at 12:51 PM, Harry Sukumar hsukumar@bond.edu.au wrote:
Dear All
I am trying to allow a local user on the centos machine to be able to run yum
What I have done is added him to the wheel group so that he can run software, basically it's his own machine if he breaks it it's his problem
But even after adding him to wheel, sys and adm group he is unable to install using yum
I am sure I must be missing something or I must be doing something wrong,
Many Thanks
Harry
_______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Harry Sukumar wrote:
Hi James,
Yes I tried to do this on another machine unfortunately this didn't work for me, good you raised this topic
On the other machine I edited the visudo
User_Alias PROJECT = emma, paddy, sb PROJECT ALL = !/usr/su, !/bin/su, !/usr/bin/passwd
I see your trying to protect your users from becoming root. You do realise that with that sudo configuration a user can still run "sudo /bin/bash" or any of the other shells to gain root access.
Dean
Plant, Dean wrote:
I see your trying to protect your users from becoming root. You do realise that with that sudo configuration a user can still run "sudo /bin/bash" or any of the other shells to gain root access.
Hi Dean,
I don't think that's correct. One of the purposes of the sudoers file is you can limit users to specific programs, excluding them from others. This entry, which I just tested in my CentOS5.2 box, allows the user tldap to use yum, but not /bin/bash:- tldap ALL=/usr/bin/yum
Here's what happens when I try sudo as user tldap:- 2.6.18-92.1.1.el5.centos.plusxen[tldap@www ~]$ sudo yum update Loading "fastestmirror" plugin Loading "priorities" plugin Loading mirror speeds from cached hostfile * base: rsync.atworks.co.jp * updates: rsync.atworks.co.jp * centosplus: mirror.exetel.com.au * addons: mirror.exetel.com.au * extras: mirror.exetel.com.au 0 packages excluded due to repository priority protections Setting up Update Process No Packages marked for Update 2.6.18-92.1.1.el5.centos.plusxen[tldap@www ~]$ sudo /bin/bash Sorry, user tldap is not allowed to execute '/bin/bash' as root on www 2.6.18-92.1.1.el5.centos.plusxen[tldap@www ~]$
Cheers,
Ian
Ian Blackwell wrote:
Plant, Dean wrote:
I see your trying to protect your users from becoming root. You do realise that with that sudo configuration a user can still run "sudo /bin/bash" or any of the other shells to gain root access.
Hi Dean,
I don't think that's correct. One of the purposes of the sudoers file is you can limit users to specific programs, excluding them from others. This entry, which I just tested in my CentOS5.2 box, allows the user tldap to use yum, but not /bin/bash:- tldap ALL=/usr/bin/yum
Here's what happens when I try sudo as user tldap:- 2.6.18-92.1.1.el5.centos.plusxen[tldap@www ~]$ sudo yum update Loading "fastestmirror" plugin Loading "priorities" plugin Loading mirror speeds from cached hostfile
- base: rsync.atworks.co.jp
- updates: rsync.atworks.co.jp
- centosplus: mirror.exetel.com.au
- addons: mirror.exetel.com.au
- extras: mirror.exetel.com.au
0 packages excluded due to repository priority protections Setting up Update Process No Packages marked for Update 2.6.18-92.1.1.el5.centos.plusxen[tldap@www ~]$ sudo /bin/bash Sorry, user tldap is not allowed to execute '/bin/bash' as root on www 2.6.18-92.1.1.el5.centos.plusxen[tldap@www ~]$
Yes you are correct in your example only yum would run and no exclude is required. We can not see from his posting exactly what commands he is allowing as he is calling groups.
What I was trying to point out is that if is he is disabling commands like su then they must be enabled somewhere in the groups he is calling and it is good practice to disable all the shells as well. All my sudoers lines that call groups like he was trying to do always have a !SU, !SHELLS to specifically deny root access.
Anyway I will shut up now as none of this will help fix his problem.
Dean
Plant, Dean wrote:
What I was trying to point out is that if is he is disabling commands like su then they must be enabled somewhere in the groups he is calling and it is good practice to disable all the shells as well. All my sudoers lines that call groups like he was trying to do always have a !SU, !SHELLS to specifically deny root access.
Noted.
Anyway I will shut up now as none of this will help fix his problem.
Ditto :-)
In a flurry of recycled electrons Plant, Dean wrote:
All my sudoers lines that call groups like he was trying to do always have a !SU, !SHELLS to specifically deny root access.
Anyway I will shut up now as none of this will help fix his problem.
If you ever grant someone ALL commands and then try and restrict them from getting a root shell your fighting a loosing battle. Vi/Vim as root can bang out to a root shell, more can bang out to a root shell, and what's to stop someone from writing a shell script and executing it as root?
You may already have this covered and I'm not directing this specifically at your post, but I've seen some really poorly written sudoers files that open up huge holes.
I know this isn't contributing either so I'm going to lunch!
Just a point of note:
When adding the wheel group to the sudoers file via visudo, it does not mean that the users in the wheel group can execute commands directly. It means that they can type:
#sudo command options
For each enabled command in the sudoers file.
Now lets walk through some examples from my sudoers file:
jpyeron ALL=(ALL) NOPASSWD: ALL
## allows user jpyeron logged in from ALL locations to act as ALL users without confirming jpyeron's password and execute ALL programs.
# Uncomment to allow people in group wheel to run all commands # %wheel ALL=(ALL) ALL
## allows users in the wheel group logged in from ALL locations to act as ALL users executing ALL programs.
# Same thing without a password # %wheel ALL=(ALL) NOPASSWD: ALL
## allows users in the wheel group logged in from ALL locations to act as ALL without confirming his password users executing ALL programs.
# Samples # %users ALL=/sbin/mount /cdrom,/sbin/umount /cdrom
## allows users in the users group logged in from ALL locations to act as root and run either "/sbin/mount /cdrom" or "/sbin/umount /cdrom" without deviation of the command line.
# %users localhost=/sbin/shutdown -h now
## allows users in the users group logged in from localhost (or console?) to act as root and execute "/sbin/shutdown -h now" only.
/* I gave up on quoting html emails... */
-- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100 - - +1 (443) 269-1555 x333 Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, purge the message from your system and notify the sender immediately. Any other use of the email by you is prohibited.
On Fri, Jun 27, 2008 at 10:17:22AM -0400, Jason Pyeron wrote:
jpyeron ALL=(ALL) NOPASSWD: ALL
## allows user jpyeron logged in from ALL locations to act as ALL users without
Not logged in _from_ all locations; logged in _to_ all machines which have that sudoers file.
eg jpyeron A=(root) /bin/cat /etc/A jpyeron B=(root) /bin/cat /etc/B jpyeron ALL=(root) /bin/cat /etc/C means that on machine A you can cat /etc/A and on machine B you can /etc/B and on all machines you can cat /etc/C.
This allows you to have one centrally controlled sudoers file but have machine specific privileges.
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Stephen Harris Sent: Friday, June 27, 2008 10:31 AM To: CentOS mailing list Subject: Re: [CentOS] Wheel and YUM!!
On Fri, Jun 27, 2008 at 10:17:22AM -0400, Jason Pyeron wrote:
jpyeron ALL=(ALL) NOPASSWD: ALL
## allows user jpyeron logged in from ALL locations to act as ALL users without
Not logged in _from_ all locations; logged in _to_ all machines which have that sudoers file.
eg jpyeron A=(root) /bin/cat /etc/A jpyeron B=(root) /bin/cat /etc/B jpyeron ALL=(root) /bin/cat /etc/C means that on machine A you can cat /etc/A and on machine B you can /etc/B and on all machines you can cat /etc/C.
Doh!
This allows you to have one centrally controlled sudoers file but have machine specific privileges.
Hmmm, I don't see it in /etc/nsswitch.conf.
By central you mean identical copies?
-- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100 - - +1 (443) 269-1555 x333 Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, purge the message from your system and notify the sender immediately. Any other use of the email by you is prohibited.
On Fri, Jun 27, 2008 at 10:34:46AM -0400, Jason Pyeron wrote:
[mailto:centos-bounces@centos.org] On Behalf Of Stephen Harris
This allows you to have one centrally controlled sudoers file but have machine specific privileges.
Hmmm, I don't see it in /etc/nsswitch.conf.
By central you mean identical copies?
Yes, or stored in an LDAP tree (sudo can pull from LDAP) or whatever. Large environments may maintain a single sudoers file centrally that is pushed to all managed machines, for example.