On 1999-12-14, Thomas Lockhart mentioned:
> That seems to be a bit heavy handed; why bother disallowing things in
> the backend because some (small number of) shell-based tools have
> trouble as clients? I'd prefer filtering that at the client end, and
It's really about statements like this:
snprintf(buf, sizeof(buf), "rm -rf '%s'", path);
There is no way around disallowing single-quotes unless you double quote
the argument and be very careful with the escaping. Of course this
particular case might as well use unlink(), but there is a recursive copy
of the template1 dir which would take a little more work (opendir(),
etc.). At that point we could lift that restriction.
> permissions. I haven't looked at the code in a long time, but was
> thinking about recoding ACLs as a two-field type to enforce an
> unambigous interpretation of the two fields. Interested??
I've been puzzled about this for a long time, is there a reason this is
stored as an array at all? Why not use tuples likeaclperm char?aclrelation oidaclentity oid /* user or
groupsysid */aclisgroup bool /* is it a user or group? */
And then it looks like this:
aclperm|aclrel|acluser|aclisgroup
-------+------+-------+----------
R |177777| 100|f
W |177777| 100|f
R |177777| 120|f
R |188888| 5|t
That's much cleaner. GRANT and REVOKE would be reduced to simple
insert/delete equivalents. I'm not sure how the actual authentication code
would like that overheadwise, though.
A related issue is pg_group, which I'm currently working on. Those arrays
are killing me. A simple user/group associating relation would be much
nicer.
--
Peter Eisentraut Sernanders väg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden