Yes, there is a count, a type, and a list of extents -- I was just
thinking from a permission checking perspective. There's no associated
directory or file or anything that would have permissions associated
with it, if that makes sense?
Rob
On Jun 24, 2009, at 9:27 PM, Walter Ligon wrote:
I assume there is also a parameter to specify how many objects to
create?
Capabilities can only be created by a server, and the server must be
trusted by the receiving server (which has its public key). We
could create a special credential for server-to-server ops I suppose.
I'm not entirely clear what the issue is with all this, I'm hoping
htye will shed some light on it.
Walt
Rob Ross wrote:
Hi Walt,
I'm curious about this too. The only input parameter of note in the
batch_create request is the FSID, so there isn't much to work with
in terms of permission checking...
Nick, are you developing some mechanism to differentiate servers
from clients? Or is there some sort of special "I'm a server"
credential that would allow these operations to proceed?
Is your goal to eliminate clients creating datafiles on their own
entirely, or to simply limit the rate at which a malicious client
could consume resources? If the latter, you could simply place an
upper limit on the number of objects that a non-server client could
create in one request (assuming you have a way to differentiate)...
Thanks,
Rob
On Jun 24, 2009, at 4:18 PM, Walter Ligon wrote:
Nick, how are you planning to handle the bulk-create in the first
place?
Clearly we don't want to require a distinct capability for each
object being requested, so I assume the requesting server will
provide a capability with the number of objects IN the capability
so its signed.
Then it could be passed safely to the user.
Walt
Nicholas Mills wrote:
When I say new create code I'm referring to the changes to the
server's create.sm <http://create.sm> and the corresponding
changes to the client's sys-create.sm <http://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.
Thanks for your response,
Nick
On Wed, Jun 24, 2009 at 2:03 PM, Sam Lang <[email protected] <mailto:[email protected]
>> wrote:
On Jun 24, 2009, at 9:22 AM, Nicholas Mills wrote:
Hey all,
Can someone quickly explain to me why sys-symlink.sm
<http://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
[email protected]
<mailto:[email protected]>
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
------------------------------------------------------------------------
_______________________________________________
Pvfs2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-
developers
_______________________________________________
Pvfs2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
_______________________________________________
Pvfs2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
