Dremio Cloud (next-gen): privileges not inherited from project level, and GRANT OWNERSHIP on a UDF has no effect

Dremio Cloud
1

Hello everyone,

Im having two permission issues on Dremio Cloud (next-gen projects) — I’d like to know if they’re expected behavior or bugs.

1) Privileges don’t cascade down the hierarchy. When I grant full privileges on the project to a user or role, they can browse the catalog and see the objects, but SELECT on a view fails. To make it work, I have to grant privileges on every folder in the path, one level at a time, down to the folder holding the VDS. With deeply nested structures this doesn’t scale. Shouldn’t privileges granted at the project level be inherited by the child folders and views?

its not following the inheritance explained in the docs:

2) GRANT OWNERSHIP on a UDF doesn’t change the owner. The statement completes successfully, with no error or warning, but the function still shows the original creator as its owner.

Has anyone run into either of these? Any confirmation or workaround would be appreciated.

Thanks!

2

Hi Mauricio,

Thanks for the detailed writeup, and sorry for the delay getting back to you.

On privilege inheritance: this is actually expected behavior for Open Catalog specifically (in NextGen), though it’s easy to miss. The general inheritance model you linked applies to the broader Organization → Project → Source → Folder hierarchy, but Open Catalog (the native catalog behind next-gen projects) has its own privilege model, and there USAGE is documented as needing to be granted on every folder in the hierarchy path rather than cascading down from a parent grant — see the Open Catalog Privileges table. So granting full privileges at the project level gets you catalog browsing, but SELECT on a nested view still needs USAGE on each folder down to it. This is expected behavior and provided more fine-grain control over privileges in the Open Catalog model.

On GRANT OWNERSHIP on a UDF: this one does looks like a bug rather than expected behavior — OWNERSHIP not being inherited by nested objects is by design, but a direct GRANT OWNERSHIP on the UDF itself silently not taking effect is different. Could you share the exact statement you’re running, and whether the same statement correctly transfers ownership on a view or table in the same project? That’ll help us confirm whether it’s UDF-specific and get it in front of engineering.

Thanks for your patience,
Cindy

3

Thanks for the answers!

On the privileges: I understand now. I agree that more fine-grained control is useful, but on a day-to-day basis, with a lot of users / roles / VDSs, it becomes a chore. In my opinion, the old way was simpler.

Still, thanks for the answer — now we know it’s expected behavior and not a bug!

On the ownership: it was a simple grant of a function to another user:

GRANT OWNERSHIP ON FUNCTION <function_name> TO "<username>";

The result comes back as “OK”, but when we describe the function, it’s still owned by the original user who created it.

We followed the docs and looked for anything out of the ordinary, but found nothing — it just doesn’t seem to work as intended.

Thanks,
Mauricio Lorenzo Macri