9:14 a.m.
User scenarios:
Users may create template from ISOs from shallow/deep scan or from
a user specified local path. Because kimchid runs as root and have
access of most ISOs scanned. For qemu, however, the real user to start a
vm, does not always have access of the ISO to install a vm. Under this
circumstance, we need to denote that:
1. On scanning, indicate which ISOs may not be accessible by qemu user.
2. When create a template from an ISO which qemu does not have access ,
ask if user want to fix permission, if not, disable the template.
3. If user accept fix permission, change permission of template cdrom.
Rest API will look like:
1. scanning and report
GET /storagepools/pool-1/storagevolumes/iso-volume
{'type': 'raw', 'path': '/home/i-am-an-iso.iso',
'accessible': False}
2. Create template
POST /templates
{'name': 'template-1'
'cdrom': 'a-b-c'} "a-b-c.iso" not accessible by qemu
---->
{'name': 'template-1', 'status': 'disable'}
NOTE: template in 'disable' status may because of any of its
facility not active (storagepool, iso, network, etc)
3. Fix permission(Permission fix just open for template, we don't
support fix for single volume/path temporarily)
PUT /templates/t-1/cdrom {'accessible': True}
10:11 a.m.
looks good.
Just a minor comment below
On 01/13/2014 04:14 PM, Royce Lv wrote:
User scenarios:
Users may create template from ISOs from shallow/deep scan or from a
user specified local path. Because kimchid runs as root and have
access of most ISOs scanned. For qemu, however, the real user to start
a vm, does not always have access of the ISO to install a vm. Under
this circumstance, we need to denote that:
1. On scanning, indicate which ISOs may not be accessible by qemu user.
2. When create a template from an ISO which qemu does not have access
, ask if user want to fix permission, if not, disable the template.
3. If user accept fix permission, change permission of template cdrom.
Rest API will look like:
1. scanning and report
GET /storagepools/pool-1/storagevolumes/iso-volume
{'type': 'raw', 'path': '/home/i-am-an-iso.iso',
'accessible': False}
2. Create template
POST /templates
{'name': 'template-1'
'cdrom': 'a-b-c'} "a-b-c.iso" not accessible by qemu
---->
{'name': 'template-1', 'status': 'disable'}
NOTE: template in 'disable' status may because of any of its facility
not active (storagepool, iso, network, etc)
3. Fix permission(Permission fix just open for template, we don't
support fix for single volume/path temporarily)
PUT /templates/t-1/cdrom {'accessible': True}
UI should prompt some message to let user confirm to fix the permission.
--
Thanks and best regards!
Sheldon Feng(冯少合)<shaohef(a)linux.vnet.ibm.com>
IBM Linux Technology Center
7:13 a.m.
于 2014/1/13 16:14, Royce Lv 写道:
User scenarios:
Users may create template from ISOs from shallow/deep scan or from a
user specified local path. Because kimchid runs as root and have
access of most ISOs scanned. For qemu, however, the real user to start
a vm, does not always have access of the ISO to install a vm. Under
this circumstance, we need to denote that:
1. On scanning, indicate which ISOs may not be accessible by qemu user.
2. When create a template from an ISO which qemu does not have access
, ask if user want to fix permission, if not, disable the template.
3. If user accept fix permission, change permission of template cdrom.
Rest API will look like:
1. scanning and report
GET /storagepools/pool-1/storagevolumes/iso-volume
{'type': 'raw', 'path': '/home/i-am-an-iso.iso',
'accessible': False}
2. Create template
POST /templates
{'name': 'template-1'
'cdrom': 'a-b-c'} "a-b-c.iso" not accessible by qemu
---->
{'name': 'template-1', 'status': 'disable'}
NOTE: template in 'disable' status may because of any of its facility
not active (storagepool, iso, network, etc)
3. Fix permission(Permission fix just open for template, we don't
support fix for single volume/path temporarily)
PUT /templates/t-1/cdrom {'accessible': True}
First of all, I don't like to fix the permission of an existing ISO to
make it accessable by qemu process. I think it is the system
administrator's responsibility to fix the permission instead of
Kimchi's. However, we can give a hint in the UI for all the ISOs found
which can not be accessed by qemu process and hint the system
administrator to do the manual fix.
_______________________________________________
Kimchi-devel mailing list
Kimchi-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/kimchi-devel
11:26 a.m.
On 01/14/2014 02:13 PM, Shu Ming wrote:
于 2014/1/13 16:14, Royce Lv 写道:
> User scenarios:
>
> Users may create template from ISOs from shallow/deep scan or from a
> user specified local path. Because kimchid runs as root and have
> access of most ISOs scanned. For qemu, however, the real user to
> start a vm, does not always have access of the ISO to install a vm.
> Under this circumstance, we need to denote that:
>
> 1. On scanning, indicate which ISOs may not be accessible by qemu user.
> 2. When create a template from an ISO which qemu does not have access
> , ask if user want to fix permission, if not, disable the template.
> 3. If user accept fix permission, change permission of template cdrom.
>
> Rest API will look like:
> 1. scanning and report
> GET /storagepools/pool-1/storagevolumes/iso-volume
> {'type': 'raw', 'path': '/home/i-am-an-iso.iso',
'accessible': False}
>
> 2. Create template
> POST /templates
> {'name': 'template-1'
> 'cdrom': 'a-b-c'} "a-b-c.iso" not accessible by qemu
> ---->
> {'name': 'template-1', 'status': 'disable'}
> NOTE: template in 'disable' status may because of any of its facility
> not active (storagepool, iso, network, etc)
>
> 3. Fix permission(Permission fix just open for template, we don't
> support fix for single volume/path temporarily)
> PUT /templates/t-1/cdrom {'accessible': True}
First of all, I don't like to fix the permission of an existing ISO to
make it accessable by qemu process. I think it is the system
administrator's responsibility to fix the permission instead of
Kimchi's. However, we can give a hint in the UI for all the ISOs found
which can not be accessed by qemu process and hint the system
administrator to do the manual fix.
Do you means we just need:
1. scanning and report
GET /storagepools/pool-1/storagevolumes/iso-volume
{'type': 'raw', 'path': '/home/i-am-an-iso.iso',
'accessible': False}
2. Create template
POST /templates
{'name': 'template-1'
'cdrom': 'a-b-c'} "a-b-c.iso" not accessible by qemu
---->
{'name': 'template-1', 'status': 'disable'}
NOTE: template in 'disable' status may because of any of its facility
not active (storagepool, iso, network, etc)
do not need
3. Fix permission(Permission fix just open for template, we don't
support fix for single volume/path temporarily)
PUT /templates/t-1/cdrom {'accessible': True}
?
>
> _______________________________________________
> Kimchi-devel mailing list
> Kimchi-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>
_______________________________________________
Kimchi-devel mailing list
Kimchi-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/kimchi-devel
--
Thanks and best regards!
Sheldon Feng(冯少合)<shaohef(a)linux.vnet.ibm.com>
IBM Linux Technology Center
3:04 a.m.
Looks good for me.
And I agree with Sheldon we need to add a change permission confirmation
on UI
Just a comment below.
On 01/13/2014 06:14 AM, Royce Lv wrote:
User scenarios:
Users may create template from ISOs from shallow/deep scan or from
a user specified local path. Because kimchid runs as root and have
access of most ISOs scanned. For qemu, however, the real user to start
a vm, does not always have access of the ISO to install a vm. Under
this circumstance, we need to denote that:
1. On scanning, indicate which ISOs may not be accessible by qemu user.
2. When create a template from an ISO which qemu does not have access
, ask if user want to fix permission, if not, disable the template.
Why should we allow a user create a template that will be disabled
because the ISO isn't accessible?
3. If user accept fix permission, change permission of template
cdrom.
Rest API will look like:
1. scanning and report
GET /storagepools/pool-1/storagevolumes/iso-volume
{'type': 'raw', 'path': '/home/i-am-an-iso.iso',
'accessible': False}
2. Create template
POST /templates
{'name': 'template-1'
'cdrom': 'a-b-c'} "a-b-c.iso" not accessible by qemu
---->
{'name': 'template-1', 'status': 'disable'}
NOTE: template in 'disable' status may because of any of its
facility not active (storagepool, iso, network, etc)
3. Fix permission(Permission fix just open for template, we don't
support fix for single volume/path temporarily)
PUT /templates/t-1/cdrom {'accessible': True}
3:35 a.m.
I don't agree to change the permission in Kimchi even there is a
permission confirmation warning. It is the responsibility of the host
system administrator to change the permission.
2014/1/16 10:04, Aline Manera:
Looks good for me.
And I agree with Sheldon we need to add a change permission
confirmation on UI
Just a comment below.
On 01/13/2014 06:14 AM, Royce Lv wrote:
> User scenarios:
>
> Users may create template from ISOs from shallow/deep scan or
> from a user specified local path. Because kimchid runs as root and
> have access of most ISOs scanned. For qemu, however, the real user to
> start a vm, does not always have access of the ISO to install a vm.
> Under this circumstance, we need to denote that:
>
> 1. On scanning, indicate which ISOs may not be accessible by qemu user.
> 2. When create a template from an ISO which qemu does not have access
> , ask if user want to fix permission, if not, disable the template.
Why should we allow a user create a template that will be disabled
because the ISO isn't accessible?
> 3. If user accept fix permission, change permission of template cdrom.
>
> Rest API will look like:
> 1. scanning and report
> GET /storagepools/pool-1/storagevolumes/iso-volume
> {'type': 'raw', 'path': '/home/i-am-an-iso.iso',
'accessible':
> False}
>
> 2. Create template
> POST /templates
> {'name': 'template-1'
> 'cdrom': 'a-b-c'} "a-b-c.iso" not accessible by qemu
> ---->
> {'name': 'template-1', 'status': 'disable'}
> NOTE: template in 'disable' status may because of any of its
> facility not active (storagepool, iso, network, etc)
>
> 3. Fix permission(Permission fix just open for template, we don't
> support fix for single volume/path temporarily)
> PUT /templates/t-1/cdrom {'accessible': True}
_______________________________________________
Kimchi-devel mailing list
Kimchi-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/kimchi-devel
3:39 a.m.
On 01/16/2014 12:35 AM, Shu Ming wrote:
I don't agree to change the permission in Kimchi even there is a
permission confirmation warning. It is the responsibility of the
host system administrator to change the permission.
And why can't kimchi provide this ability through the UI?
If admin would like to change the permission it can do it when creating
the template, otherwise skip it.
2014/1/16 10:04, Aline Manera:
>
> Looks good for me.
>
> And I agree with Sheldon we need to add a change permission
> confirmation on UI
>
> Just a comment below.
>
> On 01/13/2014 06:14 AM, Royce Lv wrote:
>> User scenarios:
>>
>> Users may create template from ISOs from shallow/deep scan or
>> from a user specified local path. Because kimchid runs as root and
>> have access of most ISOs scanned. For qemu, however, the real user
>> to start a vm, does not always have access of the ISO to install a
>> vm. Under this circumstance, we need to denote that:
>>
>> 1. On scanning, indicate which ISOs may not be accessible by qemu user.
>> 2. When create a template from an ISO which qemu does not have
>> access , ask if user want to fix permission, if not, disable the
>> template.
>
> Why should we allow a user create a template that will be disabled
> because the ISO isn't accessible?
>
>> 3. If user accept fix permission, change permission of template cdrom.
>>
>> Rest API will look like:
>> 1. scanning and report
>> GET /storagepools/pool-1/storagevolumes/iso-volume
>> {'type': 'raw', 'path':
'/home/i-am-an-iso.iso', 'accessible':
>> False}
>>
>> 2. Create template
>> POST /templates
>> {'name': 'template-1'
>> 'cdrom': 'a-b-c'} "a-b-c.iso" not accessible by
qemu
>> ---->
>> {'name': 'template-1', 'status': 'disable'}
>> NOTE: template in 'disable' status may because of any of its
>> facility not active (storagepool, iso, network, etc)
>>
>> 3. Fix permission(Permission fix just open for template, we don't
>> support fix for single volume/path temporarily)
>> PUT /templates/t-1/cdrom {'accessible': True}
>
> _______________________________________________
> Kimchi-devel mailing list
> Kimchi-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>
3:48 a.m.
On 01/16/2014 10:35 AM, Shu Ming wrote:
I don't agree to change the permission in Kimchi even there is a
permission confirmation warning. It is the responsibility of the
host system administrator to change the permission.
+1
There shouldn't be a confirmation to ask user whether to change. He is
not allowed to change the permissions at all. Consider this:
1. User A burned an ISO file which includes confidential or private
information in it and he placed it in his home directory as private files.
2. Template administrator wants to create templates so he list ISO files.
3. He found the private ISO file and changed the permission.
Then other users can sign in server OS to do whatever he wants about the
ISO file.
2014/1/16 10:04, Aline Manera:
>
> Looks good for me.
>
> And I agree with Sheldon we need to add a change permission
> confirmation on UI
>
> Just a comment below.
>
> On 01/13/2014 06:14 AM, Royce Lv wrote:
>> User scenarios:
>>
>> Users may create template from ISOs from shallow/deep scan or
>> from a user specified local path. Because kimchid runs as root and
>> have access of most ISOs scanned. For qemu, however, the real user
>> to start a vm, does not always have access of the ISO to install a
>> vm. Under this circumstance, we need to denote that:
>>
>> 1. On scanning, indicate which ISOs may not be accessible by qemu user.
>> 2. When create a template from an ISO which qemu does not have
>> access , ask if user want to fix permission, if not, disable the
>> template.
>
> Why should we allow a user create a template that will be disabled
> because the ISO isn't accessible?
>
>> 3. If user accept fix permission, change permission of template cdrom.
>>
>> Rest API will look like:
>> 1. scanning and report
>> GET /storagepools/pool-1/storagevolumes/iso-volume
>> {'type': 'raw', 'path':
'/home/i-am-an-iso.iso', 'accessible':
>> False}
>>
>> 2. Create template
>> POST /templates
>> {'name': 'template-1'
>> 'cdrom': 'a-b-c'} "a-b-c.iso" not accessible by
qemu
>> ---->
>> {'name': 'template-1', 'status': 'disable'}
>> NOTE: template in 'disable' status may because of any of its
>> facility not active (storagepool, iso, network, etc)
>>
>> 3. Fix permission(Permission fix just open for template, we don't
>> support fix for single volume/path temporarily)
>> PUT /templates/t-1/cdrom {'accessible': True}
>
> _______________________________________________
> Kimchi-devel mailing list
> Kimchi-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>
_______________________________________________
Kimchi-devel mailing list
Kimchi-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/kimchi-devel
4:26 a.m.
于 2014/1/16 10:39, Aline Manera 写道:
On 01/16/2014 12:35 AM, Shu Ming wrote:
> I don't agree to change the permission in Kimchi even there is a
> permission confirmation warning. It is the responsibility of the host
> system administrator to change the permission.
And why can't kimchi provide this ability through the UI?
If admin would like to change the permission it can do it when
creating the template, otherwise skip it.
The admin in Kimchi is different from the system administrator in the
host. All the directories in the host are owned by the system
administrator in the host. In another word, the "root" account logged in
the Kimchi is a different account than the "root" account in Linux host.
We can not assume the account in Kimchi can change the permission of the
directories in the host.
>
> 2014/1/16 10:04, Aline Manera:
>>
>> Looks good for me.
>>
>> And I agree with Sheldon we need to add a change permission
>> confirmation on UI
>>
>> Just a comment below.
>>
>> On 01/13/2014 06:14 AM, Royce Lv wrote:
>>> User scenarios:
>>>
>>> Users may create template from ISOs from shallow/deep scan or from
>>> a user specified local path. Because kimchid runs as root and have
>>> access of most ISOs scanned. For qemu, however, the real user to
>>> start a vm, does not always have access of the ISO to install a vm.
>>> Under this circumstance, we need to denote that:
>>>
>>> 1. On scanning, indicate which ISOs may not be accessible by qemu
>>> user.
>>> 2. When create a template from an ISO which qemu does not have
>>> access , ask if user want to fix permission, if not, disable the
>>> template.
>>
>> Why should we allow a user create a template that will be disabled
>> because the ISO isn't accessible?
>>
>>> 3. If user accept fix permission, change permission of template cdrom.
>>>
>>> Rest API will look like:
>>> 1. scanning and report
>>> GET /storagepools/pool-1/storagevolumes/iso-volume
>>> {'type': 'raw', 'path':
'/home/i-am-an-iso.iso', 'accessible': False}
>>>
>>> 2. Create template
>>> POST /templates
>>> {'name': 'template-1'
>>> 'cdrom': 'a-b-c'} "a-b-c.iso" not accessible by
qemu
>>> ---->
>>> {'name': 'template-1', 'status': 'disable'}
>>> NOTE: template in 'disable' status may because of any of its
>>> facility not active (storagepool, iso, network, etc)
>>>
>>> 3. Fix permission(Permission fix just open for template, we don't
>>> support fix for single volume/path temporarily)
>>> PUT /templates/t-1/cdrom {'accessible': True}
>>
>> _______________________________________________
>> Kimchi-devel mailing list
>> Kimchi-devel(a)ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>>
>
4:33 a.m.
On 2014年01月16日 10:04, Aline Manera wrote:
Looks good for me.
And I agree with Sheldon we need to add a change permission
confirmation on UI
Discussed with Sheldon and Mark, got suggestion to only use
setfacl to
fix without change mode.
If guys agree, we will adopt this mean.
Just a comment below.
On 01/13/2014 06:14 AM, Royce Lv wrote:
> User scenarios:
>
> Users may create template from ISOs from shallow/deep scan or from a
> user specified local path. Because kimchid runs as root and have
> access of most ISOs scanned. For qemu, however, the real user to
> start a vm, does not always have access of the ISO to install a vm.
> Under this circumstance, we need to denote that:
>
> 1. On scanning, indicate which ISOs may not be accessible by qemu user.
> 2. When create a template from an ISO which qemu does not have access
> , ask if user want to fix permission, if not, disable the template.
Why should we allow a user create a template that will be disabled
because the ISO isn't accessible?
If we don't allow it, we don't have
chance to fix ISO when it is given
by a full path('/home/royce/i-am-iso'), not a storagepool volume, we can
only fix it until template is constructed.
> 3. If user accept fix permission, change permission of template cdrom.
>
> Rest API will look like:
> 1. scanning and report
> GET /storagepools/pool-1/storagevolumes/iso-volume
> {'type': 'raw', 'path': '/home/i-am-an-iso.iso',
'accessible': False}
>
> 2. Create template
> POST /templates
> {'name': 'template-1'
> 'cdrom': 'a-b-c'} "a-b-c.iso" not accessible by qemu
> ---->
> {'name': 'template-1', 'status': 'disable'}
> NOTE: template in 'disable' status may because of any of its facility
> not active (storagepool, iso, network, etc)
>
> 3. Fix permission(Permission fix just open for template, we don't
> support fix for single volume/path temporarily)
> PUT /templates/t-1/cdrom {'accessible': True}
3775
days inactive
3778
days old
9 comments
5 participants
participants (5)
-
Aline Manera -
Hongliang Wang -
Royce Lv -
Sheldon -
Shu Ming