> Okay, the example you sent me off-list turns out to exhibit one bug
> and one not-yet-implemented feature. There is a bug in permissions
> checking for insert/update/delete rules (any references therein to
> NEW or OLD should be checked against the rule owner, not the calling
> user). A patch for that is attached.
Thanks, I'll apply it.
> However, you were also expecting
> that an SQL function call would provide "setuid" behavior, and it
> doesn't. (I believe changing that is on the TODO list.) In the
> meantime, you'd need to replace the current_adm() function call in your
> adm_base view rules with explicit subselects, so that the accesses to
> the "users" table are checked against the rule owner rather than the
> calling user.
Well, in fact, -at this point - I don't need setuid, because the function current_adm() has to lookup the effective uid
ofthe calling
user. The point is I want to filter the records depending on the uid of the user calling the top-level view. So as I
canunderstand,
views that are called by other views run still within the same session - thus returning the effective uid, right?
Kind Regards,
Lieven.
