[Pvfs2-developers] Batch create in sys-symlink.sm

[Sam Lang]

On Jun 24, 2009, at 3:39 PM, Nicholas Mills wrote:

> When I say new create code I'm referring to the changes to the  
> server's create.sm and the corresponding changes to the client's sys- 
> create.sm since 2.7.1 (almost all of the changes come from the small  
> file branch).
>
> It used to be that both sys-symlink and sys-create used the server  
> "create" request to create their objects. But now that create only  
> makes regular files the sys-symlink code has been modified to use  
> batch-create with a size of one. This approach works, but it seems  
> to me to be a misuse of an operation designed for the creation of  
> multiple handles between servers.
>
> As you know, David and I are working on eliminating the security  
> holes present in the current version of PVFS. I would really rather  
> not give client code the ability to create up to 8192 handles  
> (source: pvfs2-req-proto.h) with a single request.
>
> Is there any obstacle to moving the symlink creation code to the  
> server side in the same way that regular file creation was moved to  
> the server side? I realize it would involve adding yet another  
> request (and state machine), but I believe in the interest of  
> security that regular clients should not have access to the  
> functionality provided by batch-create.

There's no obstacle from an implementation perspective.  It changes  
the protocol format, which means a major version upgrade, but maybe  
that's not a big deal for the security changes you're making.

Can you describe the security holes you are trying to eliminate?
Moving the symlink doesn't allow you to eliminate the batch_create  
request from the list of requests that the server is willing to  
accept.  Servers must still send those requests to each other  
obviously, and in the default environment, we don't make distinction  
between metadata and I/O server, so metadata servers will still need  
to accept the batch_create as well.  Further, our servers don't  
differentiate between (or in-fact *can* differentiate right now)  
client requests and requests from other servers, so I don't see what  
is gained by moving symlink to the server.

It sounds like your approach to eliminating security holes is with  
"security by obscurity".  In other words, if the client (or some rogue  
process acting as a client) does not know that the interface is there,  
he can't abuse it.  I don't think that's the right approach,  
especially since PVFS is completely open source, and anyone can just  
look at the code.

-sam

>
> Thanks for your response,
>
> Nick
>
> On Wed, Jun 24, 2009 at 2:03 PM, Sam Lang <slang at mcs.anl.gov> wrote:
>
> On Jun 24, 2009, at 9:22 AM, Nicholas Mills wrote:
>
>> Hey all,
>>
>> Can someone quickly explain to me why sys-symlink.sm (in the client  
>> code) now uses batch create with a fixed size of one? What prevents  
>> us from using the new create code? This change was merged in by  
>> phil with the small files branch.
>
> What "new create code" do you refer to?  The batch create code is  
> the new create path.
> -sam
>
>>
>> Thanks,
>>
>> Nick
>> _______________________________________________
>> Pvfs2-developers mailing list
>> Pvfs2-developers at beowulf-underground.org
>> http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.beowulf-underground.org/pipermail/pvfs2-developers/attachments/20090624/0d138385/attachment.htm