Re: CREATE DATABASE

"Thomas G. Lockhart" wrote:
  >> Well, I documented what I actually had to do to make it work.
  >
  >Well, not to cause trouble here but it will work as I intended, and
  >didn't work as you tried to use it. That's not so bad, and the usage is
  >documented in the administrator's guide.

I was actually working from the existing man pages, but now that I check,
it isn't sufficiently clear from the guide that initlocation is an
administrator-only command. (Sections II.7, III.22)  Even reading them in
the light of your comments, I cannot see that this restriction is stated.
(Or have you updated this since 6.3.2?)
...
  >"initlocation" isn't actually the issue; the real issue is whether
  >alternate locations not created by the Postgres superuser should be
  >allowed at all. I'm thinking not, given these issues which would have to
  >be kept in mind by every user trying to use the command themselves.

If initlocation is to be run only by the administrator, it should be owned
by the administrator login and have execute-permission only for the
owner.
...
  >> 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
  >> use only.
  >
  >I did document it for administrators only ;)

I still don't see it!  Sorry.
...
  >At the moment, initlocation is just a shell utility which sets up a
  >directory area and changes permissions to be appropriate for Postgres
  >use *if it is run by the Postgres superuser*.

So make it executable only by the superuser.  If some site wanted to have
multiple administrators, it would need some fancy code to check that
the postmaster listening on $PGPORT was owned by the same user as is
running initlocation. Then it could be made generally executable.

  >If we are concerned that alternate database locations can be misused and
  >should be under tighter control of the Postgres superuser, then it would
  >be easy to take out (or #ifdef) the code which allows absolute path
  >names and instead require that all paths for alternate locations be
  >specified as environment variables (that is already supported and was
  >always preferable imho).
  >
  >That way the Postgres administrator can run initlocation, define an
  >environment variable pointing at that alternate location, and then start
  >up the backend. Users would have only those previously defined areas to
  >work with.

How many alternate locations can be specified? I see PGDATA2 listed in your
documentation.  Can this be extended to PGDATAn?

  >
  >I'm being pretty direct here in my comments because you are raising very
  >good issues and we haven't had much discussion of them in the past. I am
  >not intending to be difficult or obstinant, just trying to clear things
  >up and get a plan for improving things.
  >
  >Comments (on the issues, and/or whether I'm being a pain :)?

No problem!  In this case, I was documenting from the point of view of a
user, since I was running commands in my own name (with database creation
privileges).  The old man pages don't mention any restriction, so it didn't
occur to me that this was an administrator only command.  The way I read it,
it seemed to be designed for a user to set up his own private area.



--
Oliver Elphick                                Oliver.Elphick@lfix.co.uk
Isle of Wight                              http://www.lfix.co.uk/oliver
               PGP key from public servers; key ID 32B8FAA1
                 ========================================
     "In my Father's house are many mansions: if it were not
      so, I would have told you. I go to prepare a place for
      you. And if I go and prepare a place for you, I will
      come again, and receive you unto myself; that where I
      am, there ye may be also."        John 14:2,3