Re: [PATCHES] Run-as-admin warning for win32
Tom Lane said: > Bruce Momjian <[EMAIL PROTECTED]> writes: >> Tom Lane wrote: >>> Why? If we refuse to run as root on Unix, I do not see an argument >>> for being more forgiving on Windows. > >> I am not sure it is as easy to run as non-admin on Win32 as it is to >> run as non-root on Unix. Is it? > > Ease of use has nothing to do with this. Given the demonstrated > security weaknesses of Windows, we would be completely irresponsible to > allow Postgres to be started in an obviously-insecure way on that > platform. > > In other words, I do not wish to be the author of code that could > become the vector for the next SQL Slammer worm. > Me either :-) > I am already deathly afraid of what the Windows port is likely to do to > Postgres' reputation for reliability and security. Do *not* get me > started by proposing that we insert obvious security holes on lame > "ease of use" grounds. Haven't the boys in Redmond already proven the > wrongness of those priorities many times over? > If we are going to enforce the 'must be non-privileged user' on Windows, there are some things we need to do, I think: . enforce the rule in initdb (currently it does not, on Windows). . if the installer is running as Administrator, it should create a Postgres user . if the installer is going to install the service, it should run initdb as the postgres user (is that possible?) and install the service to run as that user. IOW, we need to make it as easy as possible to be secure. cheers andrew ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] Run-as-admin warning for win32
> 2. Are you sure "Powerusers" is such a good idea? It's the default for > all non-admin users. When Postgres becomes a service, it's going to be > relatively easy to configure it to run as a low-priv user. Until then, > however, isn't it too difficult for admins to set up the system for it > to run as a different user? > Found this document on the net. It gives you a good overview of what different levels of users can and cannot do. I think the heading "What can a power user do that a user can't" contains a couple of very good reasons to prevent that PostgreSQL runs with Powerusers rights. http://download.microsoft.com/download/1/b/8/1b8fc001-6f67-4ea1-b0f2-8add1da8cbc0/_Toc42414596 Exerpt: Unfortunately, these permissions are also the same permissions that allow power users to: · Introduce Trojan horses that, if executed by administrators or other users, can compromise system and data security · Make system-wide operating system and application changes that affect other users of the system Kind regards, Thomas Hallgren ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] Run-as-admin warning for win32
Thomas Hallgren wrote: http://download.microsoft.com/download/1/b/8/1b8fc001-6f67-4ea1-b0f2-8add1da8cbc0/_Toc42414596 Link does not work. Exerpt: Unfortunately, these permissions are also the same permissions that allow power users to: ? Introduce Trojan horses that, if executed by administrators or other users, can compromise system and data security ? Make system-wide operating system and application changes that affect other users of the system Kind regards, Thomas Hallgren That pathetic thing called "Windows security" is getting to me. It is close to impossible to create a "user", and once created, this user will not be capable of actually doing anything. Very flexible, very granular permissions system result in making it impossible for someone, us in this case, to find out whether we are over-priveleged. Well meaning, but horrible system, with even more horrible results. Shachar -- Shachar Shemesh Lingnu Open Source Consulting http://www.lingnu.com/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] Run-as-admin warning for win32
Sorry. That link was internal to the document. This one should work. http://download.microsoft.com/download/1/b/8/1b8fc001-6f67-4ea1-b0f2-8add1da8cbc0/SecDefs2003.doc Regards, Thomas Hallgren "Shachar Shemesh" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Thomas Hallgren wrote: > > >http://download.microsoft.com/download/1/b/8/1b8fc001-6f67-4ea1-b0f2-8add1d a8cbc0/_Toc42414596 > > > > > Link does not work. > > >Exerpt: > > > >Unfortunately, these permissions are also the same permissions that allow > >power users to: > > ? Introduce Trojan horses that, if executed by administrators or > >other users, can compromise system and data security > > ? Make system-wide operating system and application changes > >that affect other users of the system > > > >Kind regards, > > > >Thomas Hallgren > > > > > > That pathetic thing called "Windows security" is getting to me. It is > close to impossible to create a "user", and once created, this user will > not be capable of actually doing anything. > > Very flexible, very granular permissions system result in making it > impossible for someone, us in this case, to find out whether we are > over-priveleged. > > Well meaning, but horrible system, with even more horrible results. > > > Shachar > > -- > Shachar Shemesh > Lingnu Open Source Consulting > http://www.lingnu.com/ > > > ---(end of broadcast)--- > TIP 4: Don't 'kill -9' the postmaster > ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [PATCHES] Run-as-admin warning for win32
> 1. You forgot to check "localsystem", as well as "domain > admins". These two have even higher permissions than the ones > you test for, and one of them is the default if Postgre ever > makes it to become a service. Not at all. Local System is a member of the Administrators group (no, it doesn't show up as such, but if you examine the token on any local system process, you will see it has the administrators group sid in it). As is Domain Admins, if the machine is in a domain. And if it's not in a domain, Domain Admins simply does not apply. Domain admins have equal permissions on the local machine as Administrators, not more. It has more permissions on the network, but we can't really dig into that - there are a lot of other groups we need to check for as well in that case. > 2. Are you sure "Powerusers" is such a good idea? It's the > default for all non-admin users. In what installation is that the default? The default is "Users" and not "Power Users" in all my installations (which I haven't tweaked in that respect from what I know). > When Postgres becomes a > service, it's going to be relatively easy to configure it to > run as a low-priv user. Until then, however, isn't it too > difficult for admins to set up the system for it to run as a > different user? First, this is one of the reasons I go with warning and not error out. Second, I run it as a low-priv account myself using: runas /user:postgres c:\pgdev\bin\startpg.bat If you want to start it using an icon, it has the same possibilities. Or just start a commandprompt as a different user and use that one. (RunAs requires Windows2000+, that's the only limitation) //Magnus ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Run-as-admin warning for win32
> >> Why? If we refuse to run as root on Unix, I do not see an > argument > >> for being more forgiving on Windows. > > > I am not sure it is as easy to run as non-admin on Win32 as > it is to > > run as non-root on Unix. Is it? It is a little bit more tricky, but not much. I'd say it's more a factor of what people are used to. People think of their windows machine as a single user system, and their unix machine as a multi user system. On Windows 2000+ you can have multiple windows on the same windowstation running as different users (using runas). In <= NT4 you can only have services running as a different user than the one logged on to the console. > Ease of use has nothing to do with this. Given the > demonstrated security weaknesses of Windows, we would be > completely irresponsible to allow Postgres to be started in > an obviously-insecure way on that platform. Certainly a good argument. I was more into emulating the behaviour of the other available databases for windows. They normally *let* you run with high-priv accounts, but they *recommend* you don't. This is pretty much standard for most "respectable" windows products. In production, you certainly wouldn't do it. But it helps if you're setting it up in a lab for testing, for example. When you *know* what you are doing. But it can certainly be changed to an ERROR if we want. I'd still argue it should go at this place and not earlier, because we want to get the output to go where we want it. See below. > In other words, I do not wish to be the author of code that > could become the vector for the next SQL Slammer worm. While I fully agree with that statement, it is an incorrect comparison. The Slammer worm was because of a hole in SQL Server that allowed arbitrary code execution as whatever user account SQLServer was running as. It spread equally on server running as Local System, with admin privileges or (as recommended) with a low-privilege account. You don't have to be an administrator to send out UDP packets... A similar worm could just as easily hit postgresql on Unix today (eh, assuming such a security hole existed, which I'm fairly sure it doesn't, but hypothetically). It's not a factor of the platform. It's a factor of the product. Local admin privs will let a security hole in *postgresql* change/destroy parts of the *local operating system*. No more, no less. (Unless you give it domain admins, in which case in can reach other machines in the domain, of course) > I am already deathly afraid of what the Windows port is > likely to do to Postgres' reputation for reliability and > security. Do *not* get me started by proposing that we > insert obvious security holes on lame "ease of use" grounds. > Haven't the boys in Redmond already proven the wrongness of > those priorities many times over? They certainly have. In some products (like SQL Server), they've now moved to recommending against it. They're not outright preventing it. From other mail: > We could move the Unix check later without any problem. I agree with keeping both checks > in the same place. I read this as that you'd prefer to see the Unix "check-for-root"-code moved to the same place? If so, I'll update the patch with that, depending the outcome of the rest of the discussion (for example, need for ereport) //Magnus ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] win32 service proposal
> I played a bit with that code. According to Microsoft samples > for service managers, errors and events should be logged to > eventlog. so I added a function (almost copy of sample > service code), it's a messy, but it was enough to see what is > happening with the service. Consider using ereport() if it's available at that time - then it'll go to the correct place. Otherwise, look at the code in backend/utils/error/elog.c, and the write_eventlog() function. Might want to make that one non-static and call that one. That way we're sure the messages end up in the same category in the eventlog. > 1. > I'll try to describe what happens in few steps: > a.) register service using: > C:\msys\1.0\local\pgsql\bin\postmaster /register postgres -D > C:/msys/1.0/local/pgsql/data > b.) start service manager > c.) start the service (it starts fine) > d.) unregister service using: C:\msys\1.0\local\pgsql\bin\postmaster > /unregister postgres > > After that postgres "status type" in service manager changes > to "disabled", and I'm unable to do anything with service. Yes, this is normal if you unregister a service *while it is running*. > The only way is restarting NT. It seems that this happens no > matter service is started or stopped, enough is that service > manager is started and cursor is positioned on "postgres" > service. Is this some kind of Win bug ? It shuold not happen when it's not started. In that case, it should be enough to restart the services MMC snapin. Or if you're on NT4, you need to restart the control panel (uh, maybe even logout/in). But you shouldn't need a reboot. > 2. > When invalid parameter for postmaster is set, for example: -D > C:/msys/1.0/local/pgsql/dataX, CreateProcess returns true, > but postmaster exit with FATAL. How can we detect this > situation and send the postmaster error string into log ? postgresql.conf, set log_destination to eventlog. That should put it in a place you can see it. //Magnus ---(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
Re: [PATCHES] Run-as-admin warning for win32
"Andrew Dunstan" <[EMAIL PROTECTED]> writes: > . if the installer is running as Administrator, it should create a > Postgres user > IOW, we need to make it as easy as possible to be secure. No objection to that idea ... regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] win32 service proposal
On Tuesday 04 May 2004 13:47, Magnus Hagander wrote: > > I played a bit with that code. According to Microsoft samples > > for service managers, errors and events should be logged to > > eventlog. so I added a function (almost copy of sample > > service code), it's a messy, but it was enough to see what is > > happening with the service. > > Consider using ereport() if it's available at that time - then it'll go > to the correct place. Otherwise, look at the code in > backend/utils/error/elog.c, and the write_eventlog() function. Might > want to make that one non-static and call that one. That way we're sure > the messages end up in the same category in the eventlog. > Ooops, I was not aware that this already exists !!! I'll try to do as You suggested ! > > 1. > > I'll try to describe what happens in few steps: > > a.) register service using: > > C:\msys\1.0\local\pgsql\bin\postmaster /register postgres -D > > C:/msys/1.0/local/pgsql/data > > b.) start service manager > > c.) start the service (it starts fine) > > d.) unregister service using: C:\msys\1.0\local\pgsql\bin\postmaster > > /unregister postgres > > > > After that postgres "status type" in service manager changes > > to "disabled", and I'm unable to do anything with service. > > Yes, this is normal if you unregister a service *while it is running*. > > > The only way is restarting NT. It seems that this happens no > > matter service is started or stopped, enough is that service > > manager is started and cursor is positioned on "postgres" > > service. Is this some kind of Win bug ? > > It shuold not happen when it's not started. In that case, it should be > enough to restart the services MMC snapin. Or if you're on NT4, you need > to restart the control panel (uh, maybe even logout/in). But you > shouldn't need a reboot. > No, it is not running, just cursor positioned on "postgresql" service in service manager, and yes, You are right - logoff was enough. > > 2. > > When invalid parameter for postmaster is set, for example: -D > > C:/msys/1.0/local/pgsql/dataX, CreateProcess returns true, > > but postmaster exit with FATAL. How can we detect this > > situation and send the postmaster error string into log ? > > postgresql.conf, set log_destination to eventlog. That should put it in > a place you can see it. > > > //Magnus > > > ---(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 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] Run-as-admin warning for win32
> > . if the installer is running as Administrator, it should create a > > Postgres user > > > IOW, we need to make it as easy as possible to be secure. > > No objection to that idea ... I don't think we should create a postgres user. We should tell the guy who installs it to do that, and have him tell us what it is, but we should not actually go create the user for him. That is sure to annoy a lot of people. Most shops I know have standard naming conventinos, and would not want a user called "postgres" without any qualifications. I know, small point, but I think significant. The installer-skeleton I have right now permits installation as local system but recommends a user account. But that's just functionality to remove, so that's easily done. In the other case, it prompts for username and password to run as. //Magnus ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] Run-as-admin warning for win32
Magnus Hagander wrote: . if the installer is running as Administrator, it should create a Postgres user IOW, we need to make it as easy as possible to be secure. No objection to that idea ... I don't think we should create a postgres user. We should tell the guy who installs it to do that, and have him tell us what it is, but we should not actually go create the user for him. That is sure to annoy a lot of people. Most shops I know have standard naming conventinos, and would not want a user called "postgres" without any qualifications. I know, small point, but I think significant. Then how about we ask them what user it should run as, and offer them the option of an exisiting user (they pick from a list) or a new user (which we would create for them), with their choice of new user name, defaulting to Postgres? cheers andrew ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Run-as-admin warning for win32
Magnus Hagander wrote: > > > . if the installer is running as Administrator, it should create a > > > Postgres user > > > > > IOW, we need to make it as easy as possible to be secure. > > > > No objection to that idea ... > > I don't think we should create a postgres user. We should tell the guy > who installs it to do that, and have him tell us what it is, but we > should not actually go create the user for him. That is sure to annoy a > lot of people. Most shops I know have standard naming conventinos, and > would not want a user called "postgres" without any qualifications. > > I know, small point, but I think significant. > > The installer-skeleton I have right now permits installation as local > system but recommends a user account. But that's just functionality to > remove, so that's easily done. In the other case, it prompts for > username and password to run as. How would it install on an XP laptop? If I am logged in as myself and I am listed as a "Computer Administrator", do I need to create another user, and how do I do the install as that other user, and start/stop the server, and stuff like that? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] Run-as-admin warning for win32
> > The installer-skeleton I have right now permits > installation as local > > system but recommends a user account. But that's just > functionality to > > remove, so that's easily done. In the other case, it prompts for > > username and password to run as. > > How would it install on an XP laptop? If I am logged in as > myself and I am listed as a "Computer Administrator", do I > need to create another user, and how do I do the install as > that other user, and start/stop the server, and stuff like that? Yes, you need to create another user. When running as a service, just tell the installer. It should set up required permissions. Then start the service as normal using the Service Control Manager. When running manually, you will have to grant the postgres user the required permissions on the PGDATA directory. Then you can start the server using "runas". //Magnus ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] Run-as-admin warning for win32
Magnus Hagander wrote: > > > The installer-skeleton I have right now permits > > installation as local > > > system but recommends a user account. But that's just > > functionality to > > > remove, so that's easily done. In the other case, it prompts for > > > username and password to run as. > > > > How would it install on an XP laptop? If I am logged in as > > myself and I am listed as a "Computer Administrator", do I > > need to create another user, and how do I do the install as > > that other user, and start/stop the server, and stuff like that? > > Yes, you need to create another user. > When running as a service, just tell the installer. It should set up > required permissions. Then start the service as normal using the Service > Control Manager. > > When running manually, you will have to grant the postgres user the > required permissions on the PGDATA directory. Then you can start the > server using "runas". Ewe, big on security, small on ease-of-use. :-) I have never had to create a user to install any other software on my laptop. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] Run-as-admin warning for win32
> > Yes, you need to create another user. > > When running as a service, just tell the installer. It > should set up > > required permissions. Then start the service as normal using the > > Service Control Manager. > > > > When running manually, you will have to grant the postgres user the > > required permissions on the PGDATA directory. Then you can > start the > > server using "runas". > > Ewe, big on security, small on ease-of-use. :-) > > I have never had to create a user to install any other > software on my laptop. Yes, this is why I originally suggested making it a recommendation and not something enforced. It will certainly take a good lot of windows people by surprise... //Magnus ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [PATCHES] Run-as-admin warning for win32
Bruce Momjian wrote: I have never had to create a user to install any other software on my laptop. How much else that you have installed runs as a service? OTOH, I just installed apache and it is running the service as LocalSystem :-( cheers andrew ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] Run-as-admin warning for win32
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Bruce Momjian > Sent: 04 May 2004 16:08 > To: Magnus Hagander > Cc: Tom Lane; Andrew Dunstan; [EMAIL PROTECTED] > Subject: Re: [PATCHES] Run-as-admin warning for win32 > > > Magnus Hagander wrote: > > > > The installer-skeleton I have right now permits > > > installation as local > > > > system but recommends a user account. But that's just > > > functionality to > > > > remove, so that's easily done. In the other case, it prompts for > > > > username and password to run as. > > > > > > How would it install on an XP laptop? If I am logged in as > > > myself and I am listed as a "Computer Administrator", do I > > > need to create another user, and how do I do the install as > > > that other user, and start/stop the server, and stuff like that? > > > > Yes, you need to create another user. > > When running as a service, just tell the installer. It > should set up > > required permissions. Then start the service as normal using the > > Service Control Manager. > > > > When running manually, you will have to grant the postgres user the > > required permissions on the PGDATA directory. Then you can > start the > > server using "runas". > > Ewe, big on security, small on ease-of-use. :-) > > I have never had to create a user to install any other > software on my laptop. Just listening in on this thread I would be inclined to agree that the Win32 PostgeSQL should run under its own user given the history of Windows security. FWIW I know that Installshield (one of the most popular installers) and the default settings for MSI mean that only administrators can install software; so I would argue that there is no reason why the PostgreSQL installer also shouldn't require administrator privilege to run, and therefore create the postgres user account for us. I think that most of the services installed under Win32 use a separate username and password. The last installer I used that required a username and password was for a backup service and then it was simply a page in the installer that asked for a username and password to run under; both of these were set to defaults so all I had to do was click "Next" and the account was generated for me and the directory permissions set up correctly. This has the balance that the novice user will just click "Next" while the advanced user can set up a customised account to meet his/her needs. In the case of a stand-alone executable, I can see things being a little more tricky; however I don't see there being any reason why when we launch the backend we try the default username and password (postgres and "") and if that doesn't work then we ask for a new username and password from the user. I would see that this wouldn't be done in the backend but in the equivalent of the /etc/init.d/postgresql script under Win32. If people really got upset about asking for the account password on startup then I guess they would have to go for the service installation - I see this as being no different to the inconvenience of asking for a PEM passphrase when we restart Apache on our Linux servers. Finally I believe we can tighten up security from SMB/RPC-based exploits by applying the "can only logon locally" policy to the postgres account which means that SMB/RPC connections cannot be made with the default PostgreSQL username and password which is always a good thing :) Kind regards, Mark. --- Mark Cave-Ayland Webbased Ltd. Tamar Science Park Derriford Plymouth PL6 8BX England Tel: +44 (0)1752 764445 Fax: +44 (0)1752 764446 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] Run-as-admin warning for win32
Mark Cave-Ayland wrote: > Just listening in on this thread I would be inclined to agree that > the Win32 PostgeSQL should run under its own user given the history of > Windows security. FWIW I know that Installshield (one of the most > popular installers) and the default settings for MSI mean that only > administrators can install software; so I would argue that there is no > reason why the PostgreSQL installer also shouldn't require administrator > privilege to run, and therefore create the postgres user account for us. Yea, we could ask them for a username, supply a default, then if the username doesn't exist, ask if they want to create it. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[PATCHES] Function to do runtime relative directory mapping
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> I guess what you are saying is we should have a configure-time option to
> >> address configured directories via relative paths from the executable's
> >> directory, rather than absolute paths? Seems reasonable ...
>
> > Yep. In fact, why would we not use that by default?
>
> Because it'll be slower. Instead of
> /usr/local/pgsql/lib
> we'd be using something like
> /usr/local/pgsql/bin/../lib
> which is not too bad here but would get worse if the directories are not
> so close.
>
> But perhaps we can arrange for the path to be simplified down to an
> absolute form when it's constructed at backend startup? You'd need a
> routine anyway to combine the bindir path (determined by FindExec) with
> the relative path provided by configure, so maybe this routine could be
> smart about leading ../ in the configure path.
I wrote relative_path() which does the mapping from compiled src/dst to
a new path. For example:
$ tst1 /usr/local/pgsql/bin /usr/local/pgsql/lib /users/fred/pgsql/bin
/users/fred/pgsql/lib
$ tst1 /a/b/c /a/d /f/g/h
/f/d
This can be used in the backend to map from your bindir to a relative
libdir at runtime, and share too. It returns [mp]alloc'ed values, or
NULL if it can't do the tranformation.
Patch attached.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
Index: src/include/port.h
===
RCS file: /cvsroot/pgsql-server/src/include/port.h,v
retrieving revision 1.27
diff -c -c -r1.27 port.h
*** src/include/port.h 30 Apr 2004 17:52:07 - 1.27
--- src/include/port.h 4 May 2004 17:07:30 -
***
*** 26,31
--- 26,32
extern char *last_path_separator(const char *filename);
extern void canonicalize_path(char *path);
extern char *get_progname(char *argv0);
+ extern char *relative_path(const char *src, const char *dst, const char *target);
/* Portable delay handling */
extern void pg_usleep(long microsec);
Index: src/port/path.c
===
RCS file: /cvsroot/pgsql-server/src/port/path.c,v
retrieving revision 1.5
diff -c -c -r1.5 path.c
*** src/port/path.c 9 Mar 2004 04:49:02 - 1.5
--- src/port/path.c 4 May 2004 17:07:31 -
***
*** 13,21
--- 13,31
*-
*/
+ #ifndef FRONTEND
+ #include "postgres.h"
+ #else
#include "c.h"
+ #endif
#include
+ #ifndef WIN32
+ #define ISSEP(c) ((c) == '/')
+ #else
+ #define ISSEP(c) ((c) == '/' || (c) == '\\')
+ #endif
+
/*
*is_absolute_path
*/
***
*** 33,39
}
-
/*
*first_path_separator
*/
--- 43,48
***
*** 120,123
--- 129,241
return argv0;
else
return last_path_separator(argv0) + 1;
+ }
+
+
+ /*
+ *relative_path
+ *
+ *Determine the relative path for getting from 'src' to 'dst' and
+ *map that change from 'target' to a new directory.
+ */
+ char *
+ relative_path(const char *src, const char *dst, const char *target)
+ {
+ const char *dst_slash = NULL;
+ char*ret;
+ int dirs_up;
+
+ #ifdef WIN32
+ if (isalpha(*src) && src[1] == ':' &&
+ isalpha(*dst) && dst[1] == ':')
+ {
+ if (toupper(*src) != toupper(*src))
+ return NULL;/* no relative path, can't cross drive letters
*/
+ }
+
+ /* Move past drive letters */
+ if (isalpha(*src) && src[1] == ':')
+ src += 2;
+ if (isalpha(*dst) && dst[1] == ':')
+ src += 2;
+ #endif
+
+ /* If we don't have two absolute paths, give up */
+ if (!is_absolute_path(src) ||
+ !is_absolute_path(dst))
+ return NULL;
+
+ dst_slash = dst;
+
+ while (1)
+ {
+ /* Move past adjacent slashes like //, and trailing ones */
+ while (ISSEP(*src) && (ISSEP(src[1]) || !src[1]))
+ src++;
+ while (ISSEP(*dst) && (ISSEP(dst[1]) || !dst[1]))
+ dst++;
+
+ /* Paths are done or not equal? */
+ if (!*src || !*dst)
+ break;
+ #ifndef WIN32
+ if (*src != *dst)
+ break;
+ #else
+ /* Win32 filesystem is case insensitive */
+ if (toupper(*src) != toupper(*dst) &&
+ (!ISSEP(*src) || !ISSEP(*dst))) /* '/' == '\\' */
+ break;
+ #endif
+
Re: [PATCHES] [pgsql-hackers-win32] Function to do runtime relative directory
Bruce Momjian wrote:
+ if (toupper(*src) != toupper(*src))
Shouldn't this be
if (toupper(*src) != toupper(*dst))
?
For completeness, you should probably also check for network drive paths
("\\machine\sharename\foo").
I also think we should just canonicalise everything early, and then never have to
worry about / vs \ again.
I must confess I think this scheme is overkill - I can't think of a use case where one
would want a relocatable installation which would any pattern other than the one we
are thinking of for the windows binary installer. Are we taking flexibility too far?
cheers
andrew
---(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
Re: [PATCHES] [pgsql-hackers-win32] Function to do runtime relative directory
Andrew Dunstan wrote:
> Bruce Momjian wrote:
>
> >+ if (toupper(*src) != toupper(*src))
> >
> >
>
> Shouldn't this be
>
> if (toupper(*src) != toupper(*dst))
>
> ?
>
Yep, fixed.
> For completeness, you should probably also check for network
> drive paths ("\\machine\sharename\foo").
Oh, OK.
>
> I also think we should just canonicalise everything early, and
> then never have to worry about / vs \ again.
>
> I must confess I think this scheme is overkill - I can't think
> of a use case where one would want a relocatable installation
> which would any pattern other than the one we are thinking of
> for the windows binary installer. Are we taking flexibility too
> far?
This code might be used on Unix too.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] [pgsql-hackers-win32] Function to do runtime relative directory
Bruce Momjian wrote: Andrew Dunstan wrote: I must confess I think this scheme is overkill - I can't think of a use case where one would want a relocatable installation which would any pattern other than the one we are thinking of for the windows binary installer. Are we taking flexibility too far? This code might be used on Unix too. I know. I can't think of a Unix situation where you would want anything else either. If you want it relocatable, I would think that you would want movable-root/ /bin /lib /share /whatever and then you could just pick up that root and put it somewhere else and it would still work, Windows or Unix, it wouldn't matter, and you wouldn't break anything else. I guess using some other scheme you could pick up the various bits from under, say, /usr and put them in /usr/local, but it strikes me as being very messy and likely to be error prone. Maybe it's just a failure of my imagination. cheers andrew ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] new aggregate functions v2
On Sunday 02 May 2004 11:22, Fabien COELHO wrote:
> Dear patchers,
>
> please find attached my second patch submission for adding
> new aggregate functions:
>
> (1) boolean-and and boolean-or aggregates named bool_and and bool_or.
> they should correspond to standard sql every and some/any aggregates.
> they do not have the right name as there is a problem with
> the standard and the parser for some/any. Tom also think that
> the standard name is misleading because NULL are ignored.
>
> (2) bitwise integer aggregates named bit_and and bit_or for
> int2, int4, int8 and bit types. They are not standard, but I find
> them useful. I needed them once, and I'm not the first one to look for
> them.
>
>
> The patches adds:
>
> - 2 new very short strict functions for boolean aggregates in
> src/backed/utils/adt/bool.c,
> src/include/utils/builtins.h and src/include/catalog/pg_proc.h
>
> - the new aggregates declared in src/include/catalog/pg_proc.h and
> src/include/catalog/pg_aggregate.h
>
> - some documentation and validation about these new aggregates.
>
> It also updates the catalog version. It validates for me.
>
> Have a nice day,
Just a minor nibble, but could you add something to the documentation entries
that these are postgresql implementation of the sql any/some/every aggregate
functions. right now we have whole pages devoted to any/some for subqueries
and arrays, I'd like to give people looking for the sql spec aggregate
functions at least a chance of finding these.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
[PATCHES] Dollar Quoting doc patch--resend.
Neil,
Here it is :)
Cheers,
D
--
David Fetter [EMAIL PROTECTED] http://fetter.org/
phone: +1 510 893 6100 mobile: +1 415 235 3778
Remember to vote!
Index: doc/src/sgml/plperl.sgml
===
RCS file: /projects/cvsroot/pgsql-server/doc/src/sgml/plperl.sgml,v
retrieving revision 2.22
diff -2 -c -r2.22 plperl.sgml
*** doc/src/sgml/plperl.sgml14 Dec 2003 00:10:32 - 2.22
--- doc/src/sgml/plperl.sgml27 Apr 2004 21:10:23 -
***
*** 47,53
To create a function in the PL/Perl language, use the standard syntax:
! CREATE FUNCTION funcname
(argument-types) RETURNS
return-type AS '
# PL/Perl function body
! ' LANGUAGE plperl;
The body of the function is ordinary Perl code.
--- 47,54
To create a function in the PL/Perl language, use the standard syntax:
! CREATE FUNCTION funcname
! (argument-types) RETURNS
return-type AS $dollar_quote$
# PL/Perl function body
! $dollar_quote$ LANGUAGE plperl;
The body of the function is ordinary Perl code.
***
*** 66,73
! CREATE FUNCTION perl_max (integer, integer) RETURNS integer AS '
if ($_[0] > $_[1]) { return $_[0]; }
return $_[1];
! ' LANGUAGE plperl;
--- 67,74
! CREATE FUNCTION perl_max (integer, integer) RETURNS integer AS $perl_max$
if ($_[0] > $_[1]) { return $_[0]; }
return $_[1];
! $perl_max$ LANGUAGE plperl;
***
*** 89,93
! CREATE FUNCTION perl_max (integer, integer) RETURNS integer AS '
my ($a,$b) = @_;
if (! defined $a) {
--- 90,94
! CREATE FUNCTION perl_max (integer, integer) RETURNS integer AS $perl_max$
my ($a,$b) = @_;
if (! defined $a) {
***
*** 98,102
if ($a > $b) { return $a; }
return $b;
! ' LANGUAGE plperl;
--- 99,103
if ($a > $b) { return $a; }
return $b;
! $perl_max$ LANGUAGE plperl;
***
*** 120,127
);
! CREATE FUNCTION empcomp(employee) RETURNS integer AS '
my ($emp) = @_;
! return $emp->{''basesalary''} + $emp->{''bonus''};
! ' LANGUAGE plperl;
SELECT name, empcomp(employee) FROM employee;
--- 121,128
);
! CREATE FUNCTION empcomp(employee) RETURNS integer AS $empcomp$
my ($emp) = @_;
! return $emp->{'basesalary'} + $emp->{'bonus'};
! $empcomp$ LANGUAGE plperl;
SELECT name, empcomp(employee) FROM employee;
***
*** 137,146
Because the function body is passed as an SQL string literal to
! CREATE FUNCTION, you have to escape single
! quotes and backslashes within your Perl source, typically by
! doubling them as shown in the above example. Another possible
! approach is to avoid writing single quotes by using Perl's
! extended quoting operators (q[],
! qq[], qw[]).
--- 138,147
Because the function body is passed as an SQL string literal to
! CREATE FUNCTION, you have to use dollar quoting
! or escape single quotes and backslashes within your Perl source,
! typically by doubling them. Another possible approach is to avoid
! writing single quotes by using Perl's extended quoting operators
! (q[], qq[],
! qw[]).
***
*** 227,235
system operations are not allowed for security reasons:
! CREATE FUNCTION badfunc() RETURNS integer AS '
open(TEMP, ">/tmp/badfile");
print TEMP "Gotcha!\n";
return 1;
! ' LANGUAGE plperl;
The creation of the function will succeed, but executing it will not.
--- 228,236
system operations are not allowed for security reasons:
! CREATE FUNCTION badfunc() RETURNS integer AS $badfunc$
open(TEMP, ">/tmp/badfile");
print TEMP "Gotcha!\n";
return 1;
! $badfunc$ LANGUAGE plperl;
The creation of the function will succeed, but executing it will not.
Index: doc/src/sgml/plpgsql.sgml
===
RCS file: /projects/cvsroot/pgsql-server/doc/src/sgml/plpgsql.sgml,v
retrieving revision 1.37
diff -2 -c -r1.37 plpgsql.sgml
*** doc/src/sgml/plpgsql.sgml 26 Mar 2004 03:18:28 - 1.37
--- doc/src/sgml/plpgsql.sgml 27 Apr 2004 21:10:24 -
***
*** 262,272
Since the code of a PL/pgSQL function is specified in
CREATE FUNCTION as a string literal, single
!quotes inside the function body must be escaped by doubling them.
!This can lead to
!rather complicated code at times, especially if you are writing a
!function that generates other functions, as in the example in . This chart may be useful
!as a summary of the needed numbers of quotation marks in
!various situations.
--- 262,276
Since the code of a PL/pgSQL function is specified in
CREATE FUNCTION as a string literal, single
!quotes inside the function body must be
