Re: [HACKERS] Configurable path to look up dynamic libraries
On Tue, May 15, 2001 at 05:53:36PM -0400, Bruce Momjian wrote: But, if I may editorialize a little myself, this is just indicative of a 'Fortress PostgreSQL' attitude that is easy to get into. 'We've always I have to admit I like the sound of 'Fortress PostgreSQL'. :-) Ye Olde PostgreSQL Shoppe The PostgreSQL of Giza Our Lady of PostgreSQL, Ascendant PostgreSQL International Airport PostgreSQL Galactica PostgreSQL's Tavern ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Configurable path to look up dynamic libraries
Peter Eisentraut [EMAIL PROTECTED] writes: Tom Lane writes: This is of little value unless the default is intelligently chosen. The default should be $PGLIB, IMHO (inserted from configure's data). This default has little value as well. Users don't generally put their loadable modules in the same directory as a PostgreSQL installation. That's a sweeping statement with little to back it up. How do you know that the usual procedure isn't to put things in $PGLIB? That's certainly what all our contrib packages do. Even more to the point, that's certainly where the PL call handler functions are. I will consider this feature utterly without value unless it allows the standard declaration of plpgsql_call_handler to become installation-independent, viz CREATE FUNCTION plpgsql_call_handler () RETURNS OPAQUE AS 'plpgsql' LANGUAGE 'C'; This also ties in somewhat with the fact that we have no default for PGDATA, on purpose. If we can have arbitrarily located data locations the system should not have a hard-wired in default for libraries (which are usually tied to particular databases in particular database clusters). I'd be willing to accept a default path that points to somewhere under $PGDATA, although I consider this rather less useful. Maybe we could agree on a compromise two-entry default path: $PGDATA/functions:$PGLIB? That would require some initdb-time shenanigans to set up, but if you want to do it... I also envision this to be used as part of dump/restore. pg_dump might have an option do not dump full path, and it would insert a 'set dynamic_library_path'. This would work like the previous case, really. What? What value would it have for pg_dump to do a set path operation? The dump script would be unlikely to actually invoke any of the functions it's loading. By the time anyone tries to use the functions, they'd be running in a different backend with a different path setting, namely the default for the installation. If we make this parameter postmaster start only then we really don't gain anything. We don't even gain the minimal expected convenience in pg_dump because you would force all modules to reside in a certain place where administrators would least like them to be. I fail to follow this claim also. The point as far as I'm concerned is that paths mentioned in CREATE FUNCTION ought to be relative to someplace that's installation-dependent. That way, when you dump out and reload a CREATE FUNCTION command, the declaration is still good, you just have to have put a copy of the function's shlib in the right place for the new installation. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Configurable path to look up dynamic libraries
Peter Eisentraut [EMAIL PROTECTED] writes: Perhaps it would be good to make the empty path component equivalent to $libdir, e.g., Hmm, that would work, and also avoid having to figure out how to stuff $PGLIB into postgresql.conf during initdb. Sold as far as I'm concerned ... regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Configurable path to look up dynamic libraries
Tom Lane [EMAIL PROTECTED] writes: Peter Eisentraut [EMAIL PROTECTED] writes: Perhaps it would be good to make the empty path component equivalent to $libdir, e.g., Hmm, that would work, and also avoid having to figure out how to stuff $PGLIB into postgresql.conf during initdb. While on the subject of postgresql conf... shouldn't it be in sysconfdir instead of the database directory? And there's no switch to the postmaster to tell it you've put it somewhere else either. -- Trond Eivind Glomsrød Red Hat, Inc. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Configurable path to look up dynamic libraries
[EMAIL PROTECTED] (Trond Eivind =?iso-8859-1?q?Glomsr=F8d?=) writes: Tom Lane [EMAIL PROTECTED] writes: [EMAIL PROTECTED] (Trond Eivind =?iso-8859-1?q?Glomsr=F8d?=) writes: You could search in a path... first sysconfdir, then datadir. Surely the other way around. Which could work as well - or just a switch to postmaster to tell it which file to use. I could live with a datadir-then-sysconfdir path search. (It should be datadir first, since the sysconfdir file would serve as a system-wide default for multiple postmasters.) Given that approach I see no real need for a postmaster switch. Possibly the same approach should apply to all the config files we currently store in datadir? There is a security issue here: stuff stored in datadir is not visible to random other users on the machine (since datadir is mode 700), but I would not expect sysconfdir to be mode 700. We'd need to think about the implications of allowing Postgres config files to be world-visible. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Configurable path to look up dynamic libraries
Tom Lane [EMAIL PROTECTED] writes: [EMAIL PROTECTED] (Trond Eivind =?iso-8859-1?q?Glomsr=F8d?=) writes: Tom Lane [EMAIL PROTECTED] writes: [EMAIL PROTECTED] (Trond Eivind =?iso-8859-1?q?Glomsr=F8d?=) writes: You could search in a path... first sysconfdir, then datadir. Surely the other way around. Which could work as well - or just a switch to postmaster to tell it which file to use. I could live with a datadir-then-sysconfdir path search. (It should be datadir first, since the sysconfdir file would serve as a system-wide default for multiple postmasters.) Given that approach I see no real need for a postmaster switch. Possibly the same approach should apply to all the config files we currently store in datadir? There is a security issue here: stuff stored in datadir is not visible to random other users on the machine (since datadir is mode 700), but I would not expect sysconfdir to be mode 700. It could be (the RPMs specify a sysconfdir of /etc/pgsql) We'd need to think about the implications of allowing Postgres config files to be world-visible. The files doesn't need to be visible to others... -- Trond Eivind Glomsrød Red Hat, Inc. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Configurable path to look up dynamic libraries
Tom Lane [EMAIL PROTECTED] writes: [EMAIL PROTECTED] (Trond Eivind =?iso-8859-1?q?Glomsr=F8d?=) writes: You could search in a path... first sysconfdir, then datadir. Surely the other way around. Which could work as well - or just a switch to postmaster to tell it which file to use. -- Trond Eivind Glomsrød Red Hat, Inc. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Configurable path to look up dynamic libraries
[EMAIL PROTECTED] (Trond Eivind =?iso-8859-1?q?Glomsr=F8d?=) writes: There is a security issue here: stuff stored in datadir is not visible to random other users on the machine (since datadir is mode 700), but I would not expect sysconfdir to be mode 700. It could be (the RPMs specify a sysconfdir of /etc/pgsql) The usual install procedure would probably leave sysconfdir owned by root, if one likes to install in such a way that the binaries are owned by root (ie make, su root, make install). I'd object to a setup that's insecure for people who aren't using RPMs. The real bottom line here, though, is that you haven't shown me any positive reason to move the config files out of datadir. They're not broken where they are; and arguably they *are* data. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Configurable path to look up dynamic libraries
[EMAIL PROTECTED] (Trond Eivind =?iso-8859-1?q?Glomsr=F8d?=) writes: The real bottom line here, though, is that you haven't shown me any positive reason to move the config files out of datadir. It conflicts with the FHS - AFAIK, the FHS is not designed to support multiple instances of unprivileged daemons. I'm not interested in forcing Postgres into that straitjacket ... regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Configurable path to look up dynamic libraries
Tom Lane [EMAIL PROTECTED] writes: [EMAIL PROTECTED] (Trond Eivind =?iso-8859-1?q?Glomsr=F8d?=) writes: There is a security issue here: stuff stored in datadir is not visible to random other users on the machine (since datadir is mode 700), but I would not expect sysconfdir to be mode 700. It could be (the RPMs specify a sysconfdir of /etc/pgsql) The usual install procedure would probably leave sysconfdir owned by root, if one likes to install in such a way that the binaries are owned by root (ie make, su root, make install). I'd object to a setup that's insecure for people who aren't using RPMs. So make the files unreadable, if so required. The real bottom line here, though, is that you haven't shown me any positive reason to move the config files out of datadir. It conflicts with the FHS - and no, I don't consider configuration files and data as an identical item. -- Trond Eivind Glomsrød Red Hat, Inc. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Configurable path to look up dynamic libraries
Lamar Owen [EMAIL PROTECTED] writes: Just because we've always done it one way does not that one way correct make. Sure. We're one component of a system -- and the PostgreSQL Group has done such a good job of being platform agnostic that the platform and systems issues are almost second-class citizens. Indeed, that I think is the underlying issue here. It's FHS compliant cuts no ice with people who don't run FHS-layout systems, and I don't want to improve FHS compliancy at the price of making life more difficult for others. (Likewise for other RPM installation issues, as you well know ;-)) I do think that the notion of a configure file path search (datadir then sysconfdir) is reasonable if the security and file protection issues can be ironed out. But that will require some thought about separating security-critical data from not-critical data. I think we ought to keep pg_hba.conf and subsidiary files (especially password files!) in datadir *only*. I'm not sure about the other config files; up to now no one's paid any attention to security issues for those files, knowing that they were all kept in the same place. We might need to reorganize their contents. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
