[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 16/18] xenstored: use domain_is_unprivileged instead of checking conn->id



On 01/18/2012 06:44 AM, Ian Campbell wrote:
> On Thu, 2012-01-12 at 23:35 +0000, Daniel De Graaf wrote:
>> This centralizes all the permission checking for privileged domains in
>> preparation for allowing domains other than dom0 to be privileged.
>>
>> Signed-off-by: Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>
>> ---
>>  tools/xenstore/xenstored_core.c   |    6 +++---
>>  tools/xenstore/xenstored_domain.c |    8 ++++----
>>  2 files changed, 7 insertions(+), 7 deletions(-)
>>
>> diff --git a/tools/xenstore/xenstored_core.c 
>> b/tools/xenstore/xenstored_core.c
>> index 4ec63f1..eea5fd6 100644
>> --- a/tools/xenstore/xenstored_core.c
>> +++ b/tools/xenstore/xenstored_core.c
>> @@ -488,7 +488,7 @@ static enum xs_perm_type perm_for_conn(struct connection 
>> *conn,
>>              mask &= ~XS_PERM_WRITE;
>>  
>>      /* Owners and tools get it all... */
>> -    if (!conn->id || perms[0].id == conn->id
>> +    if (!domain_is_unprivileged(conn) || perms[0].id == conn->id
> 
> domain_is_unprivileged is:
>         conn && conn->domain && conn->domain->domid != 0
>         
> which isn't quite the same as the code being replaced. The difference
> appears to be the conn->id is valid for socket connections as well as
> domain connections whereas conn->domain is only present for domain
> connections.
> 
> Does this change not mean that, for the dom0-process xenstored
> configuration we now treat socket based connections as unprivileged
> where previously they would be unprivileged?

No. For dom0 socket connections, conn->domain is NULL so the connection
is not unprivileged (making it privileged). This is why sane people do not
make boolean functions test for "un" cases :)

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.