I run my chef clients not as root. I want to be able to install an rpm (the
RPM does not allow it to be relocated with --prefix, so it must go in
/usr).
I didn’t want to but it seems I need to either run the client as root or
make my user have sudo access with no password.
I decided to try the user be able to run sudo without a password to install
packages. However the ‘package’ resource does not appear to have a way to
tell it to run as a certain user.
Is this true? Is there a way or am I stuck either running the client as root
or using a bash command instead of the ‘package’ resource?
Thanks,
Tristan
Hi,
you can define your commands freely.
Example for tomcat.
Define what do you want to do (i.e. in an attribute file):
start the service
default[:tomcat][:start]= (platform == 'windows') ? 'C:\Applications\tomcat\bin\catalina.sh start' :
"sudo service tomcat start"
stop the service
default[:tomcat][:stop]= (platform == 'windows') ? 'C:\Applications\tomcat\bin\catalina.sh stop' :
"sudo service tomcat stop"
get service status. TODO: windows!?
default[:tomcat][:status]="sudo service tomcat status"
Overwrite the start,stop,... commands in your recipe:
...
service "tomcat" do
action :nothing
supports :start => true, :stop => true, :restart => true, :status => false
start_command node[:tomcat][:start]
stop_command node[:tomcat][:stop]
status_command node[:tomcat][:status]
restart_command "#{node[:tomcat][:stop]} && #{node[:tomcat][:start]}"
end
...
hope that helps.
Salu2,
Christian
On 07.12.2010, at 22:37, Tristan Sloughter wrote:
I run my chef clients not as root. I want to be able to install an rpm (the RPM does not allow it to be relocated with --prefix, so it must go in /usr).
I didn't want to but it seems I need to either run the client as root or make my user have sudo access with no password.
I decided to try the user be able to run sudo without a password to install packages. However the 'package' resource does not appear to have a way to tell it to run as a certain user.
Is this true? Is there a way or am I stuck either running the client as root or using a bash command instead of the 'package' resource?
Thanks,
Tristan
On Dec 7, 2010, at 3:08 PM, Christian Requena wrote:
Hi,
you can define your commands freely.
Example for tomcat.
Define what do you want to do (i.e. in an attribute file):
start the service
default[:tomcat][:start]= (platform == 'windows') ? 'C:\Applications
\tomcat\bin\catalina.sh start' :
"sudo service
tomcat start"
stop the service
default[:tomcat][:stop]= (platform == 'windows') ? 'C:\Applications
\tomcat\bin\catalina.sh stop' :
"sudo service
tomcat stop"
get service status. TODO: windows!?
default[:tomcat][:status]="sudo service tomcat status"
Overwrite the start,stop,... commands in your recipe:
...
service "tomcat" do
action :nothing
supports :start => true, :stop => true, :restart => true, :status
=> false
start_command node[:tomcat][:start]
stop_command node[:tomcat][:stop]
status_command node[:tomcat][:status]
restart_command "#{node[:tomcat][:stop]} && #{node[:tomcat]
[:start]}"
end
...
This is specific to the service resource, but you could certainly
build your own provider (which would be 99% identical to the existing
RPM provider) which uses sudo in the command.
--Noah
Another thing you can try is to make /usr group writable to the
"admin" group. And add your user on the admin group. Then installing
packages without sudo. The initial chowning of directories will
require sudo however.
On Wed, Dec 8, 2010 at 7:26 AM, Noah Kantrowitz noah@coderanger.net wrote:
On Dec 7, 2010, at 3:08 PM, Christian Requena wrote:
Hi,
you can define your commands freely.
Example for tomcat.
Define what do you want to do (i.e. in an attribute file):
start the service
default[:tomcat][:start]= (platform == 'windows') ?
'C:\Applications\tomcat\bin\catalina.sh start' :
"sudo service tomcat
start"
stop the service
default[:tomcat][:stop]= (platform == 'windows') ?
'C:\Applications\tomcat\bin\catalina.sh stop' :
"sudo service tomcat
stop"
get service status. TODO: windows!?
default[:tomcat][:status]="sudo service tomcat status"
Overwrite the start,stop,... commands in your recipe:
...
service "tomcat" do
action :nothing
supports :start => true, :stop => true, :restart => true, :status =>
false
start_command node[:tomcat][:start]
stop_command node[:tomcat][:stop]
status_command node[:tomcat][:status]
restart_command "#{node[:tomcat][:stop]} && #{node[:tomcat][:start]}"
end
...
This is specific to the service resource, but you could certainly build your
own provider (which would be 99% identical to the existing RPM provider)
which uses sudo in the command.
--Noah
I don't think the approach with the groups will work. You need sudo to
run rpm/yum, because of the rpm db.
--CR
On 12/08/2010 09:57 AM, Dreamcat4 wrote:
Another thing you can try is to make /usr group writable to the
"admin" group. And add your user on the admin group. Then installing
packages without sudo. The initial chowning of directories will
require sudo however.
On Wed, Dec 8, 2010 at 7:26 AM, Noah Kantrowitznoah@coderanger.net wrote:
On Dec 7, 2010, at 3:08 PM, Christian Requena wrote:
Hi,
you can define your commands freely.
Example for tomcat.
Define what do you want to do (i.e. in an attribute file):
start the service
default[:tomcat][:start]= (platform == 'windows') ?
'C:\Applications\tomcat\bin\catalina.sh start' :
"sudo service tomcat
start"
stop the service
default[:tomcat][:stop]= (platform == 'windows') ?
'C:\Applications\tomcat\bin\catalina.sh stop' :
"sudo service tomcat
stop"
get service status. TODO: windows!?
default[:tomcat][:status]="sudo service tomcat status"
Overwrite the start,stop,... commands in your recipe:
...
service "tomcat" do
action :nothing
supports :start => true, :stop => true, :restart => true, :status =>
false
start_command node[:tomcat][:start]
stop_command node[:tomcat][:stop]
status_command node[:tomcat][:status]
restart_command "#{node[:tomcat][:stop]}&& #{node[:tomcat][:start]}"
end
...
This is specific to the service resource, but you could certainly build your
own provider (which would be 99% identical to the existing RPM provider)
which uses sudo in the command.
--Noah
For the sake of argument, what's to stop a bad guy from installing a
setuid shell (or whatever) via yum/rpm if he gains access to your
package system?
Adding a privilege separation/non-root mode to Chef is something I
think about from time to time, but every design I come up with has a
trivial workaround for the attacker.
Dan DeLeo
On Wed, Dec 8, 2010 at 2:12 AM, Christian Requena crekev@googlemail.com wrote:
I don't think the approach with the groups will work. You need sudo to run
rpm/yum, because of the rpm db.
--CR
On 12/08/2010 09:57 AM, Dreamcat4 wrote:
Another thing you can try is to make /usr group writable to the
"admin" group. And add your user on the admin group. Then installing
packages without sudo. The initial chowning of directories will
require sudo however.
On Wed, Dec 8, 2010 at 7:26 AM, Noah Kantrowitznoah@coderanger.net
wrote:
On Dec 7, 2010, at 3:08 PM, Christian Requena wrote:
Hi,
you can define your commands freely.
Example for tomcat.
Define what do you want to do (i.e. in an attribute file):
start the service
default[:tomcat][:start]= (platform == 'windows') ?
'C:\Applications\tomcat\bin\catalina.sh start' :
"sudo service tomcat
start"
stop the service
default[:tomcat][:stop]= (platform == 'windows') ?
'C:\Applications\tomcat\bin\catalina.sh stop' :
"sudo service tomcat
stop"
get service status. TODO: windows!?
default[:tomcat][:status]="sudo service tomcat status"
Overwrite the start,stop,... commands in your recipe:
...
service "tomcat" do
action :nothing
supports :start => true, :stop => true, :restart => true, :status
=>
false
start_command node[:tomcat][:start]
stop_command node[:tomcat][:stop]
status_command node[:tomcat][:status]
restart_command "#{node[:tomcat][:stop]}&& #{node[:tomcat][:start]}"
end
...
This is specific to the service resource, but you could certainly build
your
own provider (which would be 99% identical to the existing RPM provider)
which uses sudo in the command.
--Noah
Yeah, it is not secure. I wish there was a way to make this more secure, but
none of the options seemed to give that.
My plan to is to soon remove the need for this by having the software that
configures the OS and users to also install this necessary RPM.
Tristan
On Wed, Dec 8, 2010 at 11:18 AM, Daniel DeLeo dan@kallistec.com wrote:
For the sake of argument, what's to stop a bad guy from installing a
setuid shell (or whatever) via yum/rpm if he gains access to your
package system?
Adding a privilege separation/non-root mode to Chef is something I
think about from time to time, but every design I come up with has a
trivial workaround for the attacker.
Dan DeLeo
On Wed, Dec 8, 2010 at 2:12 AM, Christian Requena crekev@googlemail.com
wrote:
I don't think the approach with the groups will work. You need sudo to
run
rpm/yum, because of the rpm db.
--CR
On 12/08/2010 09:57 AM, Dreamcat4 wrote:
Another thing you can try is to make /usr group writable to the
"admin" group. And add your user on the admin group. Then installing
packages without sudo. The initial chowning of directories will
require sudo however.
On Wed, Dec 8, 2010 at 7:26 AM, Noah Kantrowitznoah@coderanger.net
wrote:
On Dec 7, 2010, at 3:08 PM, Christian Requena wrote:
Hi,
you can define your commands freely.
Example for tomcat.
Define what do you want to do (i.e. in an attribute file):
start the service
default[:tomcat][:start]= (platform == 'windows') ?
'C:\Applications\tomcat\bin\catalina.sh start' :
"sudo service
tomcat
start"
stop the service
default[:tomcat][:stop]= (platform == 'windows') ?
'C:\Applications\tomcat\bin\catalina.sh stop' :
"sudo service
tomcat
stop"
get service status. TODO: windows!?
default[:tomcat][:status]="sudo service tomcat status"
Overwrite the start,stop,... commands in your recipe:
...
service "tomcat" do
action :nothing
supports :start => true, :stop => true, :restart => true, :status
=>
false
start_command node[:tomcat][:start]
stop_command node[:tomcat][:stop]
status_command node[:tomcat][:status]
restart_command "#{node[:tomcat][:stop]}&&
#{node[:tomcat][:start]}"
end
...
This is specific to the service resource, but you could certainly build
your
own provider (which would be 99% identical to the existing RPM
provider)
which uses sudo in the command.
--Noah
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Conceptually, running Chef as root is no different then running any
other system management utility as root - package managers included.
Chef should be able to do just about anything in your system if you
want it to be useful, and that means using unrestrained sudo doesn't
add much security - think about an execute resource running with sudo,
that is all the attacker needs to get unrestricted root access.
It will be very, very, very hard to make chef run as non-root user in
a secure mode. It will require a complex sudoers files and will
probably limit chef's ability to manage stuff. You will have to change
the sudoers files manually every time you add some new resource (cause
deploying sudoers with chef will allow an attacker to replace it with
his version) - i think the point is clear.
In short, Chef is root - both practically and conceptually. You should
protect your chef infrastructure the same as you would protect any
other systemwide root mechanism.
Avishai
On 08/12/10 19:18, Daniel DeLeo wrote:
For the sake of argument, what's to stop a bad guy from installing a
setuid shell (or whatever) via yum/rpm if he gains access to your
package system?
Adding a privilege separation/non-root mode to Chef is something I
think about from time to time, but every design I come up with has a
trivial workaround for the attacker.
Dan DeLeo
On Wed, Dec 8, 2010 at 2:12 AM, Christian Requena
crekev@googlemail.com wrote:
I don't think the approach with the groups will work. You need sudo to run
rpm/yum, because of the rpm db.
--CR
On 12/08/2010 09:57 AM, Dreamcat4 wrote:
Another thing you can try is to make /usr group writable to the
"admin" group. And add your user on the admin group. Then installing
packages without sudo. The initial chowning of directories will
require sudo however.
On Wed, Dec 8, 2010 at 7:26 AM, Noah Kantrowitznoah@coderanger.net
wrote:
On Dec 7, 2010, at 3:08 PM, Christian Requena wrote:
Hi,
you can define your commands freely.
Example for tomcat.
Define what do you want to do (i.e. in an attribute file):
start the service
default[:tomcat][:start]= (platform == 'windows') ?
'C:\Applications\tomcat\bin\catalina.sh start' :
"sudo service tomcat
start"
stop the service
default[:tomcat][:stop]= (platform == 'windows') ?
'C:\Applications\tomcat\bin\catalina.sh stop' :
"sudo service tomcat
stop"
get service status. TODO: windows!?
default[:tomcat][:status]="sudo service tomcat status"
Overwrite the start,stop,... commands in your recipe:
...
service "tomcat" do
action :nothing
supports :start => true, :stop => true, :restart => true, :status
=>
false
start_command node[:tomcat][:start]
stop_command node[:tomcat][:stop]
status_command node[:tomcat][:status]
restart_command "#{node[:tomcat][:stop]}&& #{node[:tomcat][:start]}"
end
...
This is specific to the service resource, but you could certainly build
your
own provider (which would be 99% identical to the existing RPM provider)
which uses sudo in the command.
--Noah
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJM/97nAAoJEHL26nkoW+BRqgUP/R235uudBsBlS1aAPS8ikGw5
QgxngMiqYkLD3Q/HJ74DO9QATCnUc2sUWhObyEsWOj5DXUjRY0kkTtG6CLcdJcxK
G8ovBbJhlc14i0+RuebTDT3D1rB1AsqsTdbtD8hwZoFIex22IBVQSIL24g3WJZJy
IoAhocm1Bv7BSx9xShs3KHTSqr7TgnbIzJhyhhvyKn4wVIqpsM9DsFH3t5U5abv2
KjECzatPGnvNYyRxMRFoahjlLrpeW3Ij8ZLnRkn4ZXk1Xtnfi7vc7jvKsTGMc/WN
FOh4uE/NmewLyNx4t8x9N+MkCjGntuALI+93rTU6sMjPiy+g5fUAsFiLtRo/mpnz
jmuAYGiHaPvuOimTgUcsKB9Uss39Klz3qq32Qi1cVC+7p7YgHsZPbnMzurH7FiS6
q0RkB5MiumvHvR/567oI7PNdD9T9CvSYQBYV7hGIWpY5BJVze0VEbeqJgMBPJiME
jblJrw0FPc4/V+f5NOr0mSVNioArvKpG3gUawMJv51Rd22DoZDDT1QMiQY64a8mb
Yjk2X2nARUWILL6sbp8g19hgbdRqIEHc6nkkBMKYi5UcYw0n6N8b/L1j0dAbYMxy
mfWI1maG7ytc2L1wWGhHywprY+Zl4zZKNGH4LwpazT3NFp5uADfAOyamPNT6mWoQ
O4bHcqZc0uAWAXzU+jrc
=PBYv
-----END PGP SIGNATURE-----