Re: [PATCH] dmtf reference implementation initial checkin

[Justin Clift <jc...@redhat.com>]

On 29/09/2011, at 9:34 AM, David Lutterkort wrote:
Hi Tong,
> 
> On Wed, 2011-09-28 at 11:33 -0700, email4tong@gmail.com wrote:
>> From: Tong Li <li...@us.ibm.com>
> 
> first off, congrats, the patch applies now without any warnings. We are
> making progress ;)
> 
> I have quite a few comments:

Just noticed something really old, but might still be important as it
sounds indicative of a security problem.

<snip>
>      * ... The
>        mock driver stores its files in /var/tmp (how well does that
>        actually work under Windows ?)

Just to ask the question, does this mean we have an information leak
here, where "other users on a server" can potentially get details?

Also thinking "race condition", if more than one user is doing stuff
with mock at the same time.  (?) If such a race can occur, and affect
more than just mock, sounds like an easy DoS any time there's a self
service user interface.  (ie Aeolus)

Regards and best wishes,

Justin Clift

--
Aeolus Community Manager
http://www.aeolusproject.org

Re: [PATCH] dmtf reference implementation initial checkin

[David Lutterkort <lu...@redhat.com>]

On Thu, 2011-10-20 at 08:55 +1100, Justin Clift wrote:
> On 29/09/2011, at 9:34 AM, David Lutterkort wrote:
> Just noticed something really old, but might still be important as it
> sounds indicative of a security problem.
> 
> <snip>
> >      * ... The
> >        mock driver stores its files in /var/tmp (how well does that
> >        actually work under Windows ?)
> 
> Just to ask the question, does this mean we have an information leak
> here, where "other users on a server" can potentially get details?
> 
> Also thinking "race condition", if more than one user is doing stuff
> with mock at the same time.  (?) If such a race can occur, and affect
> more than just mock, sounds like an easy DoS any time there's a self
> service user interface.  (ie Aeolus)

The mock driver is not safe at all, almost by design. It's not too hard
for two concurrent requests to clobber each other. On the plus side,
there's no race between users, since the mock driver only supports a
single user, 'mockuser'. Just to be clear: the mock driver is a toy,
useful for development, and for showing Deltacloud to your mom. Not much
more.

Other drivers do not share those limitations, since they do not use
serevr-local storage, and the remote (cloud) storage they use, as in the
case of the vSphere driver, should be safe from any sort of
concurrent-write issues. Though a review to that end would be much
appreciated.

David

Re: [PATCH] dmtf reference implementation initial checkin

[Tong Li <li...@us.ibm.com>]

The current implementation does not save anything. The persistence means
needs to be discussed further for operations which have not been
implemented. If you notice some of the xml files, these xml files are
actually used as default value sets for dmtf cimi entities. Thanks.

Tong Li
Emerging Technologies & Standards
B062/K317
litong01@us.ibm.com



From:	Justin Clift <jc...@redhat.com>
To:	deltacloud-dev@incubator.apache.org
Date:	10/19/2011 05:56 PM
Subject:	Re: [PATCH] dmtf reference implementation initial checkin



On 29/09/2011, at 9:34 AM, David Lutterkort wrote:
Hi Tong,
>
> On Wed, 2011-09-28 at 11:33 -0700, email4tong@gmail.com wrote:
>> From: Tong Li <li...@us.ibm.com>
>
> first off, congrats, the patch applies now without any warnings. We are
> making progress ;)
>
> I have quite a few comments:

Just noticed something really old, but might still be important as it
sounds indicative of a security problem.

<snip>
>      * ... The
>        mock driver stores its files in /var/tmp (how well does that
>        actually work under Windows ?)

Just to ask the question, does this mean we have an information leak
here, where "other users on a server" can potentially get details?

Also thinking "race condition", if more than one user is doing stuff
with mock at the same time.  (?) If such a race can occur, and affect
more than just mock, sounds like an easy DoS any time there's a self
service user interface.  (ie Aeolus)

Regards and best wishes,

Justin Clift

--
Aeolus Community Manager
http://www.aeolusproject.org

Re: [PATCH] dmtf reference implementation initial checkin

["marios@redhat.com" <ma...@redhat.com>]

On 20/10/11 00:55, Justin Clift wrote:
> 
> Just noticed something really old, but might still be important as it
> sounds indicative of a security problem.
> 
> <snip>
>>      * ... The
>>        mock driver stores its files in /var/tmp (how well does that
>>        actually work under Windows ?)
> 
> Just to ask the question, does this mean we have an information leak
> here, where "other users on a server" can potentially get details?
> 

The 'files' that mock driver stores are the 'yaml' files that model each
resource collection - e.g. yaml files describing images that are listed
when the client does GET /api/images. So nothing sensitive like
credentials/anything else interesting...

> Also thinking "race condition", if more than one user is doing stuff
> with mock at the same time.  (?) If such a race can occur, and affect
> more than just mock, sounds like an easy DoS any time there's a self
> service user interface.  (ie Aeolus)

Depends ... the Rakefile under /path/to/deltacloud/server looks for an
environment variable called 'DELTACLOUD_MOCK_STORAGE' - if this is set
then the yaml files go there. Otherwise, they are stored under
/var/tmp/deltacloud-mock-UNSERNAME/ so they will be different for each
user. In theory if two users have the same 'DELTACLOUD_MOCK_STORAGE'
then there might be conflict. Also, I'm not sure how well all this plays
out if you are using Windows.

marios


> 
> Regards and best wishes,
> 
> Justin Clift
> 
> --
> Aeolus Community Manager
> http://www.aeolusproject.org
> 
>