"Thomas G. Lockhart" wrote:
>Was looking through the new docs and noticed that the example for
>creating a database in an alternate location has trouble:
> $ mkdir private_db
> $ initlocation ~/private_db
> Creating Postgres database system directory
> $ chmod a+rx private_db
> $ chmod a+rwx private_db/base
> $ psql
>The chmod's are a Bad Idea (tm) since it blows the security assumptions
>for Postgres. The protections are explicitly set by initlocation to lock
>down these directories.
Well, I documented what I actually had to do to make it work.
I got the impression that this particular feature had not been properly
>I guess that the alternate location setup (initlocation) was really
>meant as a tool for the Postgres administrator, not for individual
>users. If users create alternate locations, and then for example create
>a database and then delete the directories from the file system rather
>than through Postgres things will become ugly.
Shouldn't it cope with this possibility anyway? (The mad systems
administrator....) What would happen to PostgreSQl if a database
directory disappeared from under it?
> The assumption is that
>the administrator is likely to be more careful since she is likely to be
>more aware of the issues.
If so, the restriction should be placed in the code: only the postgres
administrator should be allowed to run the command. That would get rid
of the permissions problems. On the other hand, it would remove most of
the point of having a separate location (seeing that it could just as
well be implemented by symbolic links).
>I have (or had) some #ifdef code which _requires_ that environment
>variables be used to specify alternate locations, rather than allowing
>absolute paths also. This helps ensure that locations are used which
>have been set up by the Postgres administrator, since the admin must
>have defined the environment variables for the backend before it starts
>I'm not sure how to write an example which had initlocation being run by
>someone other than the Postgres superuser while still being clear on
>these security/integrity issues. What would you suggest?
The first thing to do is decide whether this feature is required at all.
I'm trying to think of things in its favour:
1. It enables the administrator to direct a large database to a partition
with sufficient space.
2. It allows especially sensitive data to be stored on an encrypted file
3. It allows a database to be created on removable media. (Is this a good
If run by a user:
4. It might give the chance of having data that is secure against the
administrator, but only if a backend can be launched that is owned by
the user rather than by the administrator.
Since 4 isn't possible at the moment, there seems to be no reason for
allowing a user to run this command, even if he is otherwise allowed to
create databases. Removing the ability from users means that the
documentation can be simplified by documenting it for administrative
Even simpler is to remove it altogether and let the administrator
handle 1-3 by unix commands and symbolic links.
Oliver Elphick Oliver(dot)Elphick(at)lfix(dot)co(dot)uk
Isle of Wight http://www.lfix.co.uk/oliver
PGP key from public servers; key ID 32B8FAA1
"Let not your heart be troubled: ye believe in God,
believe also in me." John 14:1
pgsql-hackers by date
|Next:||From: Huw Rogers||Date: 1998-05-15 20:26:53|
|Subject: mmap vs read/write|
|Previous:||From: Bruce Momjian||Date: 1998-05-15 13:51:07|
|Subject: Re: [HACKERS] Re: [INTERFACES] Group/Order by not in target - Was [NEW ODBC DRIVER]|