PnfsHandler allows acces to file metadata in non-listable directory via pnfsid

[alrossi]

trafficstars

chimera:/pnfs/fs/usr/test# ls total 29 ... drwxrwx--- 127 2904 5023 512 Oct 02 2014 css

FILE: path: /pnfs/fs/usr/test/css/ac0293b9.086fexp0.8885 id: 000500000000000000247420

USER: 8773 1530

Using the RESTful api (which relies on the PnfsHandler constructed with user Subject),

curl -X GET "https://dmsdca06.fnal.gov:3880/api/v1/id/000500000000000000247420" -H "accept: application/json"

I still can get full metadata for the file.

[alrossi]

Note that the property (this is master) is left at its default:

pnfsmanager.enable.full-path-permission-check = true

[alrossi]

Is this a bug, or expected behavior?

[paulmillar]

The full-path-permission-check option is unrelated.

That option controls whether, given a path, PnfsManager should check each ancestor directory to verify the user is allowed to "cd into" that directory; e.g., given the path /dir-1/dir-2/file, does PnfsManager check whether the user can "cd into" /dir-1? With full-path-permission-check switched off, PnfsManager doesn't check. This is a backwards-compaibility option that (very likely) should be dropped.

For comparison, the dcap protocol allows (or, in the past, allowed) direct access to a file's content if the client knows the PNFS-ID. The rational was that, in order the know the PNFS-ID, the client must have had access to that file's parent directory. IIRC, we dropped support in dcap for PNFS-ID based access because this assumption turned out to be wrong: PNFS-IDs are not really, truly secret.

Therefore, in order to be correct, the frontend and/or PnfsManager should verify that the user is entitled to see the attributes of the file/directory with this PNFS-ID. This would involve walking the namespace backwards (id-to-path) to learn if the user is allowed to access each directory in that path. This is a rather expensive operation (although there are some DB optimisations possible). It's made worse because a file may have multiple namespace entries (i.e., hard links). PnfsManager would need to keep searching the hard links, looking for one that allows the user to see the file's attributes.

IMHO, the better approach would be either to limit this feature to the root user (or any one with the "admin" role, or to drop this API altogether. The rational for dropping it is that the client should never need to know a file's PNFS-ID: that's dCache-internal business; however, more work would be needed to support this.

[DmitryLitvintsev]

I vouch that this is expected behavior. You see you need to know file ID to get the metadata which is not possible if you can't query it by path. IOW, Al, the situation you created is rather contrived. You have obtained the PNFSID of a file using "elevated" access privilege, and now, your PNFSID sort of become a "bearer token" that allows you to query metadata for it.

I am not sure I agree that this call has to be limited to "admin/root" user. I would leave things as they are. OR, I would carefully check what kind of metadata is returned on "id" resource and see if it is the same as on path. If we make sure that user can get the same info by path, the id resource can be just dropped. I see no reason to provide inode lookup (which is a rather internal thing) to end user.

In the past I noticed that I could not get the same info using path that I can get on id resource. On path you get something closer to "ls" whereas id resource gives you a lot of internal dCache info.

Dmitry

[alrossi]

I just got back from out of town and haven't had a chance to read these carefully (I will), but dropping access via pnfsid would mean half of the drill-down capabilities in the admin panels of dCacheView would not work.

[DmitryLitvintsev]

So here we go. I would leave it as is ;)

[paulmillar]

OK, my final comments.

1. a user knowing the PNFS-ID of a file (or directory) does NOT mean that user has permission to stat that file. IIRC, there are circumstances where dCache will leak PNFS-ID information.
2. Only the admin panels of dCacheView need the /api/v1/id/ resources, which is only for admins.

So, does this really matter? I don't know; however, limiting access (to the /api/v1/id resources) to admins would seem not to break anything and would reduce the risk of this blowing up in our face.

[alrossi]

That brings us back to some atavistic issues concerning transfer info, which we did not want to be limited to admins.

Perhaps it is time to readdress the separation of the admin interface from the user dCacheView, and include only a limited version of active transfer info where you can't drill down for the user.

I would be willing to look at this, but I also think that if DESY is indeed getting a developer to work on REST/frontend/dView, perhaps this should be left to that person?

[alrossi]

P.S., I did not bump this issue because I felt a special urgency to this question. It was four years old and I was going back through unresolved issues and came across this.