snazy commented on issue #137: URL: https://github.com/apache/polaris/issues/137#issuecomment-2306474650
RLAC/CLAC is IMO a very useful functionality/feature to restrict access to sensitive information to trusted client (e.g. query engines). Masking/hiding is technically probably the more straght-forward part, but getting "trust" right is tricky. A table (or view referencing such a table directly or indirectly) that has CLAC/RLAC enabled, must not be accessible to untrusted clients, simply because once you give those access, they technically see everything. Or the catalog would have to intercept (and rewrite) manifest-lists, manifest-files and data/delete files according to the user's privileges and R/CLAC rules (masking) - that's quite expensive. However, if you have an engine/client that you _really trust_ to securely apply the CLAC/RLAC filters, the catalog can grant access to it and rely on the engine/client to do the right thing. "Trust" itself has very different meanings for different people. Some say they're fine with running queries only on that engine X, Y or Z. Others say that the engine must run on extremely locked down hardware, ensuring that malicious users must not even be able to use side-channel attacks to get (some) knowledge of the protected data. Don't get me wrong, definitely don't wanna shoot this down or so - it's the opposite. Just saying, that there's a lot of work to do. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
