public inbox for [email protected]help / color / mirror / Atom feed
current_role of caller of a DEFINER function 3+ messages / 3 participants [nested] [flat]
* current_role of caller of a DEFINER function @ 2024-06-26 08:35 Dominique Devienne <[email protected]> 0 siblings, 2 replies; 3+ messages in thread From: Dominique Devienne @ 2024-06-26 08:35 UTC (permalink / raw) To: [email protected] Hi. I was led to believe (by an hallucination...) that I could know the current_role of the caller of a DEFINER function, but after actual experimentation, turns out it shows the OWNER of the function, and not the current_role of the caller. I foolishly thought curent_role != current_user inside the DEFINER function, but reading back the doc, it's clear current_role = current_user = user, thus that was wishful thinking. Only session_user is representative of the caller, and reliable (modulo SUPERUSER and SET AUTHORIZATION, but that's a different story and kinda normal) So I have two questions: 1) Is there any way to know the current_role of the caller of a DEFINER function. I fear the answer is no, but better be sure from experts here. 2) Why isn't there a way to obtain the above? What harm would it be? Obviously for #2, distinguishing current_role from current_user inside DEFINER is a no-go, for backward compatibility. But could a new variable be invented for that? What obvious technical reason I'm missing would make that harmful or difficult? As to the use-case, now that I have a queue mechanism for tasks to be delegated to services, I need to make sure the poster of the task has the right privileges, so I wanted to capture session_user and current_role of the "poster", and the service would use that info, reliably captured (inside the DEFINER function to post a task), using ROLEs and GRANTs and other app-specific permission data. LOGIN users have different persona in the system, so the current_role matters, to determine whether the connection posting the task to be processed asynchronously by a service is allowed or not. I'd think I'm not the only one that would need something like this, no? Thanks, --DD ^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: current_role of caller of a DEFINER function @ 2024-06-26 09:08 Laurenz Albe <[email protected]> parent: Dominique Devienne <[email protected]> 1 sibling, 0 replies; 3+ messages in thread From: Laurenz Albe @ 2024-06-26 09:08 UTC (permalink / raw) To: Dominique Devienne <[email protected]>; [email protected] On Wed, 2024-06-26 at 10:35 +0200, Dominique Devienne wrote: > So I have two questions: > 1) Is there any way to know the current_role of the caller of a > DEFINER function. I fear the answer is no, but better be sure from > experts here. > 2) Why isn't there a way to obtain the above? What harm would it be? Just te be certain, let me ask a question back: If a SECURITY DEFINER function calls another SECURITY DEFINER function, which role would you like to get: 1. the invoker that called the first function 2. the owner of the first function (which is the user that called the second function) Yours, Laurenz Albe ^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: current_role of caller of a DEFINER function @ 2024-06-26 10:11 [email protected] parent: Dominique Devienne <[email protected]> 1 sibling, 0 replies; 3+ messages in thread From: [email protected] @ 2024-06-26 10:11 UTC (permalink / raw) To: Dominique Devienne <[email protected]>; [email protected] Dominique Devienne: > 1) Is there any way to know the current_role of the caller of a > DEFINER function. I fear the answer is no, but better be sure from > experts here. You can do something like this: CREATE DOMAIN current_user_only AS text CONSTRAINT current_user_only CHECK (VALUE = CURRENT_USER); CREATE FUNCTION func( calling_user current_user_only DEFAULT CURRENT_USER ) ... SECURITY DEFINER; The default value will be evaluated in the context of the calling user, the constraint forces it to never be set explicitly to something else. Thus you can use calling_user inside your function. Best, Wolfgang ^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2024-06-26 10:11 UTC | newest] Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2024-06-26 08:35 current_role of caller of a DEFINER function Dominique Devienne <[email protected]> 2024-06-26 09:08 ` Laurenz Albe <[email protected]> 2024-06-26 10:11 ` [email protected]
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox