Re: AW: "setuid" functions, a solution to the RI privilege problem

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at>
Cc: "Ross J(dot) Reedstrom" <reedstrm(at)rice(dot)edu>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: AW: "setuid" functions, a solution to the RI privilege problem
Date: 2000-09-17 10:14:49
Message-ID: Pine.LNX.4.21.0009170403150.1088-100000@peter
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Zeugswetter Andreas SB writes:

> Imho it is fine to get rid of the usesysid in our internal
> authorization system, but we should not get rid of the only field that
> can tie a db user to an os user. Imho we should not do a "by name"
> lookup and eliminate the field.

Um, well, the only possible way to determine the session user when the
backend starts is to use the textual user name provided by the
authentication subsystem.

> The extra field adds additional flexibility, like using one os user
> for many db users, or using different names for os users.

> In the long run we will need a tie to os users for os level setuid
> user functions.

But the pg_shadow authentication is based on credentials provided by the
client whereas what you propose here would run on the server, so this
doesn't make sense. When we get around to these setuid user functions
(while I have no idea how we would do so) we certainly need to have a
separate control mechanism.

--
Peter Eisentraut peter_e(at)gmx(dot)net http://yi.org/peter-e/

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2000-09-17 10:29:16 Re: Cannot compile
Previous Message Bruce Momjian 2000-09-17 02:58:33 Re: your mail