[Lustre-devel] Queries regarding LDLM_ENQUEUE

Nikita Danilov Nikita_Danilov at xyratex.com
Wed Oct 20 01:38:44 PDT 2010


On 20 October 2010 12:30, <bzzz.tomas at gmail.com> wrote:

> On 10/20/10 12:24 PM, Andreas Dilger wrote:
> > I'm reluctant to expose the whole FID namespace to applications, since
> this completely bypasses all directory permissions and allows opening files
> only based on their inode permissions.  If we require a name_to_handle()
> syscall to succeed first, before allowing open_by_handle() to work, then at
> least we know that one of the involved processes was able to do a full path
> traversal.
>
> yes, this is a good point. can be solved if you use FID +
> capability/signature ?
>
> >> another idea was to do whole path traversal on MDS within a single RPC.
> >> bug that'd require amount of changes to llite and/or VFS and keep MDS
> >> a bottleneck.
> >
> > This was discussed a long time ago, and has the potential drawback that
> if one of the path components is over-mounted on the client (e.g. local
> RAM-based tmpfs on a Lustre root filesystem) then the MDS-side path
> traversal would be incorrect.  It could return an entry underneath the
> mountpoint, instead of inside it.
>
> yes, and that could be solved if server returns a series of FIDs,
> then client could check whether any of those is over-mounted?
>

This is what sufficiently smart nfsv4 clients are supposed to do, by the
way, I believe: issue a compound RPC with a sequence of LOOKUP requests and
traverse returned sequence of file-id-s locally, checking for mount points.

Nikita.


>
> thanks, z
>
> _______________________________________________
> Lustre-devel mailing list
> Lustre-devel at lists.lustre.org
> http://lists.lustre.org/mailman/listinfo/lustre-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lustre.org/pipermail/lustre-devel-lustre.org/attachments/20101020/ae9ad024/attachment.htm>


More information about the lustre-devel mailing list