Kun Huang wrote:
Thanks, Thierry Carrez. Your explanation is easy to understand. I have
got why we need such a mechanism.
BTW, is root-wrap a general or popular way to keep security? I have no
experience on security, but I have heard the /root /should be banned
because of security. Ideally,
Hi, all:
In this wiki, http://wiki.openstack.org/Nova/Rootwrap, the part of
security model results in This chain ensures that the nova user itself
is not in control of the configuration or modules used by the nova-rootwrap
executable. I understand that chain but I`m confused with this conclusion.
Kun Huang wrote:
In this wiki, http://wiki.openstack.org/Nova/Rootwrap, the part of
security model results in This chain ensures that the nova user
itself is not in control of the configuration or modules used by the
nova-rootwrap executable. I understand that chain but I`m confused with
this
On Fri, Jan 11, 2013 at 11:32:08AM +0100, Thierry Carrez wrote:
Kun Huang wrote:
In this wiki, http://wiki.openstack.org/Nova/Rootwrap, the part of
security model results in This chain ensures that the nova user
itself is not in control of the configuration or modules used by the
Daniel P. Berrange wrote:
FWIW, if you've got libguestfs available, the file injection code does
not require any rootwrap usage. Ironically the config drive stuff now
does require root if you configure it to use FAT instead of ISO9660 :-(
My issue is that we enable a very permissive
Thanks, Thierry Carrez. Your explanation is easy to understand. I have got
why we need such a mechanism.
BTW, is root-wrap a general or popular way to keep security? I have no
experience on security, but I have heard the *root *should be banned
because of security. Ideally, should we ban *root
6 matches
Mail list logo
