> 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 of the 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 can understand,
views that are called by other views run still within the same session - thus
returning the effective uid, right?
Kind Regards,
Lieven.
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
