Re: [libvirt] [PATCH RFC 1/3] security_dac: Remember owner prior chown() and restore on relabel

2013-03-01 Thread Daniel P. Berrange
On Fri, Mar 01, 2013 at 09:42:57AM +0100, Michal Privoznik wrote: > On 28.02.2013 02:22, Eric Blake wrote: > > On 02/27/2013 02:25 AM, Michal Privoznik wrote: > >>> Are you really planning on storing a string uid:gid? Wouldn't it be > >>> simpler to store a uid_t and gid_t as read from struct stat

Re: [libvirt] [PATCH RFC 1/3] security_dac: Remember owner prior chown() and restore on relabel

2013-03-01 Thread Michal Privoznik
On 28.02.2013 02:22, Eric Blake wrote: > On 02/27/2013 02:25 AM, Michal Privoznik wrote: >>> Are you really planning on storing a string uid:gid? Wouldn't it be >>> simpler to store a uid_t and gid_t as read from struct stat, as long as >>> the data is only in memory? And when storing the data to

Re: [libvirt] [PATCH RFC 1/3] security_dac: Remember owner prior chown() and restore on relabel

2013-02-27 Thread Eric Blake
On 02/27/2013 02:25 AM, Michal Privoznik wrote: >> Are you really planning on storing a string uid:gid? Wouldn't it be >> simpler to store a uid_t and gid_t as read from struct stat, as long as >> the data is only in memory? And when storing the data to disk in XML to >> survive libvirtd restarts

Re: [libvirt] [PATCH RFC 1/3] security_dac: Remember owner prior chown() and restore on relabel

2013-02-27 Thread Daniel P. Berrange
On Wed, Feb 27, 2013 at 11:30:31AM +0100, Michal Privoznik wrote: > On 27.02.2013 11:21, Daniel P. Berrange wrote: > > On Tue, Feb 26, 2013 at 05:08:40PM +0100, Michal Privoznik wrote: > >> Currently, if we label a file to match qemu process DAC label, we > >> do not store the original owner anywhe

Re: [libvirt] [PATCH RFC 1/3] security_dac: Remember owner prior chown() and restore on relabel

2013-02-27 Thread Michal Privoznik
On 27.02.2013 11:21, Daniel P. Berrange wrote: > On Tue, Feb 26, 2013 at 05:08:40PM +0100, Michal Privoznik wrote: >> Currently, if we label a file to match qemu process DAC label, we >> do not store the original owner anywhere. So when relabeling >> back, the only option we have is to relabel to r

Re: [libvirt] [PATCH RFC 1/3] security_dac: Remember owner prior chown() and restore on relabel

2013-02-27 Thread Daniel P. Berrange
On Tue, Feb 26, 2013 at 05:23:18PM -0700, Eric Blake wrote: > On 02/26/2013 09:08 AM, Michal Privoznik wrote: > > Currently, if we label a file to match qemu process DAC label, we > > do not store the original owner anywhere. So when relabeling > > back, the only option we have is to relabel to roo

Re: [libvirt] [PATCH RFC 1/3] security_dac: Remember owner prior chown() and restore on relabel

2013-02-27 Thread Daniel P. Berrange
On Tue, Feb 26, 2013 at 05:08:40PM +0100, Michal Privoznik wrote: > Currently, if we label a file to match qemu process DAC label, we > do not store the original owner anywhere. So when relabeling > back, the only option we have is to relabel to root:root > which is obviously wrong. > > However, b

Re: [libvirt] [PATCH RFC 1/3] security_dac: Remember owner prior chown() and restore on relabel

2013-02-27 Thread Michal Privoznik
On 27.02.2013 01:23, Eric Blake wrote: > On 02/26/2013 09:08 AM, Michal Privoznik wrote: >> Currently, if we label a file to match qemu process DAC label, we >> do not store the original owner anywhere. So when relabeling >> back, the only option we have is to relabel to root:root >> which is obvio

Re: [libvirt] [PATCH RFC 1/3] security_dac: Remember owner prior chown() and restore on relabel

2013-02-26 Thread Eric Blake
On 02/26/2013 09:08 AM, Michal Privoznik wrote: > Currently, if we label a file to match qemu process DAC label, we > do not store the original owner anywhere. So when relabeling > back, the only option we have is to relabel to root:root > which is obviously wrong. > > However, bare remembering is

[libvirt] [PATCH RFC 1/3] security_dac: Remember owner prior chown() and restore on relabel

2013-02-26 Thread Michal Privoznik
Currently, if we label a file to match qemu process DAC label, we do not store the original owner anywhere. So when relabeling back, the only option we have is to relabel to root:root which is obviously wrong. However, bare remembering is not enough. We need to keep track of how many times we labe