The short version goes like this - every request has a signed capability
included with it that states the request is authorized. The capability
is created by one of the servers, which we trust. We don't need to know
the source of any given message because we can verify the source of the
capab
Sorry to keep everyone waiting. I promise I'm working on a response to all
your questions but it may be until tomorrow (at work) when I have all the
answers.
Until then,
Nick
On Wed, Jun 24, 2009 at 9:30 PM, Sam Lang wrote:
>
> On Jun 24, 2009, at 3:55 PM, Sam Lang wrote:
>
>>
>> It sounds like
On Jun 24, 2009, at 3:55 PM, Sam Lang wrote:
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 t
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
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 specia
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
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 bot
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
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 br
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.
Thanks,
Nick
11 matches
Mail list logo
