Re: How to change the pgsql source code and build it??

Hello,
I need to initialize the db as the root and start the database server. In
order to accomplish this, I modified the initdb.c source file of pgsql
package and tried to compile it. Eventhough the build was successful, I
couldn't see the root user able to execute initdb executable generated by
the build. I wanted to know if there is any other procedure for building
the postgresql procedure?

Thanks
Shreesha.

P.S
Below is the changes done in initdb.c (shown in bold letters below)
-------------------------------------------------------------------------------------------------------------------------------
static char *
get_id(void)
{
#ifndef WIN32

struct passwd *pw;

// if (geteuid() == 0) /* 0 is root's uid */
*/* {*
* fprintf(stderr,*
* _("%s: cannot be run as root\n"*
* "Please log in (using, e.g., \"su\") as
the "*
* "(unprivileged) user that will\n"*
* "own the server process.\n"),*
* progname);*
* exit(1);*
* }*
**/*
...
}

At 2014-06-12 16:08:05 -0700, shreesha1988(at)gmail(dot)com wrote:
>
> I need to initialize the db as the root and start the database server.

Why?

-- Abhijit

I need to port pgsql onto a controller which doesn't have a framework of
creating multiple users for administrative purposes. The entire controller
is managed by a single root user and that is the reason I am trying to
change the pgsql initdb behavior. Do you think of any other better
alternative?

On Thu, Jun 12, 2014 at 5:40 PM, Abhijit Menon-Sen <ams(at)2ndquadrant(dot)com>
wrote:

> At 2014-06-12 16:08:05 -0700, shreesha1988(at)gmail(dot)com wrote:
> >
> > I need to initialize the db as the root and start the database server.
>
> Why?
>
> -- Abhijit
>

--
~Shreesha.

Hi,

> I need to port pgsql onto a controller which doesn't have a framework of
> creating multiple users for administrative purposes. The entire controller
> is managed by a single root user and that is the reason I am trying to
> change the pgsql initdb behavior. Do you think of any other better
> alternative?

The reason you didn't see initdb completed is that it execs
postgres on the way.

As you know, it is strongly discourged on ordinary environment,
but that framework sounds to be a single-user environment like
what MS-DOS was, where any security risk comes from the
characterisc is acceptable.

I could see initdb and postgres operating as root for the moment
(which means any possible side-effect is not checked) by making
changes at four point in the whole postgresql source
tree. Perhaps only two of them are needed for your wish.

postgresql $ find . -type f -print | xargs grep -nH 'geteuid() == 0'
./src/backend/main/main.c:377: if (geteuid() == 0)
./src/bin/pg_ctl/pg_ctl.c:2121: if (geteuid() == 0)
./src/bin/initdb/initdb.c:778: if (geteuid() == 0) /* 0 is root's uid */
./src/bin/pg_resetxlog/pg_resetxlog.c:250: if (geteuid() == 0)

Try replacing these conditions with "(0 && geteuid() == 0)" and
you would see it run as root.

--
Kyotaro Horiguchi
NTT Open Source Software Center

On Thu, Jun 12, 2014 at 10:59 PM, Kyotaro HORIGUCHI <
horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> wrote:

> Hi,
>
> > I need to port pgsql onto a controller which doesn't have a framework of
> > creating multiple users for administrative purposes. The entire
> controller
> > is managed by a single root user and that is the reason I am trying to
> > change the pgsql initdb behavior. Do you think of any other better
> > alternative?
>
> The reason you didn't see initdb completed is that it execs
> postgres on the way.
>
> As you know, it is strongly discourged on ordinary environment,
> but that framework sounds to be a single-user environment like
> what MS-DOS was, where any security risk comes from the
> characterisc is acceptable.
>
> I could see initdb and postgres operating as root for the moment
> (which means any possible side-effect is not checked) by making
> changes at four point in the whole postgresql source
> tree. Perhaps only two of them are needed for your wish.
>
> postgresql $ find . -type f -print | xargs grep -nH 'geteuid() == 0'
> ./src/backend/main/main.c:377: if (geteuid() == 0)
> ./src/bin/pg_ctl/pg_ctl.c:2121: if (geteuid() == 0)
> ./src/bin/initdb/initdb.c:778: if (geteuid() == 0)
> /* 0 is root's uid */
> ./src/bin/pg_resetxlog/pg_resetxlog.c:250: if (geteuid() == 0)
>
> Try replacing these conditions with "(0 && geteuid() == 0)" and
> you would see it run as root.
>
>
Maybe a compile option like '--enable-run-as-root' could be added to allow
it without the need of change the source code.

Regards,

--
Fabrízio de Royes Mello
Consultoria/Coaching PostgreSQL
>> Timbira: http://www.timbira.com.br
>> Blog sobre TI: http://fabriziomello.blogspot.com
>> Perfil Linkedin: http://br.linkedin.com/in/fabriziomello
>> Twitter: http://twitter.com/fabriziomello

=?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= <fabriziomello(at)gmail(dot)com> writes:
> On Thu, Jun 12, 2014 at 10:59 PM, Kyotaro HORIGUCHI <
> horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> wrote:
>> Try replacing these conditions with "(0 && geteuid() == 0)" and
>> you would see it run as root.

> Maybe a compile option like '--enable-run-as-root' could be added to allow
> it without the need of change the source code.

If we wanted it to be easy to run PG as root, those tests wouldn't be
there in the first place. We don't want that, so there will never be
anything to override that policy as easily as setting a configure option.

In the case at hand, the OP wants to run on some weird system that
apparently doesn't have multiple users at all. It's a pretty safe bet
that hacking out those geteuid tests is just the tip of the iceberg of
what he's going to have to change to make it work, because it probably
deviates from typical-Unix-environment in a lot of other ways too.
So I can't get too concerned about how easy this one aspect is for him.

regards, tom lane

@Fabrizio de Royes Mello, Even upon making changes as per your suggestion,
I could see that initdb is failing for the same reason:
*******************************************************************************************************************
/mswitch/pgsql/bin # ./initdb -D ../data/
The files belonging to this database system will be owned by user "root".
This user must also own the server process.

The database cluster will be initialized with locale "C".
The default database encoding has accordingly been set to "SQL_ASCII".
The default text search configuration will be set to "english".

Data page checksums are disabled.

fixing permissions on existing directory ../data ... ok
creating subdirectories ... ok
selecting default max_connections ... 10
selecting default shared_buffers ... 400kB
creating configuration files ... ok
creating template1 database in ../data/base/1 ... "root" execution of the
PostgreSQL server is not permitted.
The server must be started under an unprivileged user ID to prevent
possible system security compromise. See the documentation for
more information on how to properly start the server.
child process exited with exit code 1
initdb: removing contents of data directory "../data"
*******************************************************************************************************************

Please let me know if I need to make changes in any other place. Appreciate
your help!

On Fri, Jun 13, 2014 at 9:43 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> =?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= <fabriziomello(at)gmail(dot)com> writes:
> > On Thu, Jun 12, 2014 at 10:59 PM, Kyotaro HORIGUCHI <
> > horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> wrote:
> >> Try replacing these conditions with "(0 && geteuid() == 0)" and
> >> you would see it run as root.
>
> > Maybe a compile option like '--enable-run-as-root' could be added to
> allow
> > it without the need of change the source code.
>
> If we wanted it to be easy to run PG as root, those tests wouldn't be
> there in the first place. We don't want that, so there will never be
> anything to override that policy as easily as setting a configure option.
>
> In the case at hand, the OP wants to run on some weird system that
> apparently doesn't have multiple users at all. It's a pretty safe bet
> that hacking out those geteuid tests is just the tip of the iceberg of
> what he's going to have to change to make it work, because it probably
> deviates from typical-Unix-environment in a lot of other ways too.
> So I can't get too concerned about how easy this one aspect is for him.
>
> regards, tom lane
>

--
~Shreesha.

Like Tom said, just setting the the configure option doesn't let the root
user in. Looks like lot more changes are required.

Tom, according to you, what do you think would be my best bet to allow the
root user initialize and start the database server?

Thanks,
Shreesha.

On Fri, Jun 13, 2014 at 9:43 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> =?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= <fabriziomello(at)gmail(dot)com> writes:
> > On Thu, Jun 12, 2014 at 10:59 PM, Kyotaro HORIGUCHI <
> > horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> wrote:
> >> Try replacing these conditions with "(0 && geteuid() == 0)" and
> >> you would see it run as root.
>
> > Maybe a compile option like '--enable-run-as-root' could be added to
> allow
> > it without the need of change the source code.
>
> If we wanted it to be easy to run PG as root, those tests wouldn't be
> there in the first place. We don't want that, so there will never be
> anything to override that policy as easily as setting a configure option.
>
> In the case at hand, the OP wants to run on some weird system that
> apparently doesn't have multiple users at all. It's a pretty safe bet
> that hacking out those geteuid tests is just the tip of the iceberg of
> what he's going to have to change to make it work, because it probably
> deviates from typical-Unix-environment in a lot of other ways too.
> So I can't get too concerned about how easy this one aspect is for him.
>
> regards, tom lane
>

--
~Shreesha.

On 06/13/2014 07:08 AM, Shreesha wrote:
> I need to initialize the db as the root and start the database server

Assuming there's no way around doing this (it's generally not a good
idea), you can just use the simple program 'fakeroot'.

This program changes the return values from system calls via LD_PRELOAD,
so PostgreSQL thinks that the user it is running as isn't root. It's
commonly used in testing and packaging systems.

http://man.he.net/man1/fakeroot

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

@Craig Ringer, I am afraid I didn't understand your solution.
The scenario I am having is a system which has only user as root. I have
all the permissions and privileges of the system as the user is root. But
pgsql doesn't allow initdb to be executed by root.
I think the solution you proposed gives root permissions for a non-root
user.
But I believe, I am looking forward for the exact opposite of it. In other
words, a possible work around for a root user to execute certain
executable(s) as an unprivileged user.

On Sun, Jun 15, 2014 at 9:49 PM, Craig Ringer <craig(at)2ndquadrant(dot)com> wrote:

> On 06/13/2014 07:08 AM, Shreesha wrote:
> > I need to initialize the db as the root and start the database server
>
> Assuming there's no way around doing this (it's generally not a good
> idea), you can just use the simple program 'fakeroot'.
>
> This program changes the return values from system calls via LD_PRELOAD,
> so PostgreSQL thinks that the user it is running as isn't root. It's
> commonly used in testing and packaging systems.
>
> http://man.he.net/man1/fakeroot
>
> --
> Craig Ringer http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Training & Services
>

--
~Shreesha.

@Craig Ringer, I am afraid I didn't understand your solution.
The scenario I am having is a system which has only user as root. I have
all the permissions and privileges of the system as the user is root. But
pgsql doesn't allow initdb to be executed by root.
I think the solution you proposed gives root permissions for a non-root
user.
But I believe, I am looking forward for the exact opposite of it. In other
words, a possible work around for a root user to execute certain
executable(s) as an unprivileged user.
Please clarify if I am wrong in my understanding.

On Sun, Jun 15, 2014 at 9:49 PM, Craig Ringer <craig(at)2ndquadrant(dot)com> wrote:

> On 06/13/2014 07:08 AM, Shreesha wrote:
> > I need to initialize the db as the root and start the database server
>
> Assuming there's no way around doing this (it's generally not a good
> idea), you can just use the simple program 'fakeroot'.
>
> This program changes the return values from system calls via LD_PRELOAD,
> so PostgreSQL thinks that the user it is running as isn't root. It's
> commonly used in testing and packaging systems.
>
> http://man.he.net/man1/fakeroot
>
> --
> Craig Ringer http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Training & Services
>

--
~Shreesha.

On 06/17/2014 02:02 AM, Shreesha wrote:
> But I believe, I am looking forward for the exact opposite of it. In
> other words, a possible work around for a root user to execute certain
> executable(s) as an unprivileged user.
>

So you want the su or sudo commands?

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

Well, the initdb issue looks to be resolved. Actually, after making the
changes as suggested by Kyotaro Horiguchi, I copied only initdb binary to
my platform and didn't copy all of them. Hence, the dependencies were still
not resolved and was getting the error. However, now the database server is
started and is up and running.

But, When I try to connect the client to the server, I am getting the
following error:
****************************************************
/switch/pgsql/bin # ./psql
FATAL: database "root" does not exist
psql: FATAL: database "root" does not exist
****************************************************
Upon browsing couple of links, I learned that in order to get through with
this issue, we should login with the actual postgres user so that it will
let the client to get connected with the default database. However in my
case, I don't know why there wasn't a default database with name 'root' got
created or why the server rejects the client when it tries to connect to
the default database.

Can anyone shed some light on
1) when the default database gets created
2) how is this database 'name' is decided? Or what is the name of the
default database name?
3) Is there any other places in the database server code where this check
is applied?

Upon looking at the error I got, I believe the code is searching for the
database name == user name. If anyone can give some input on the code, it
would be helpful!

Thanks,
Shreesha

On Mon, Jun 16, 2014 at 6:58 PM, Craig Ringer <craig(at)2ndquadrant(dot)com> wrote:

> On 06/17/2014 02:02 AM, Shreesha wrote:
> > But I believe, I am looking forward for the exact opposite of it. In
> > other words, a possible work around for a root user to execute certain
> > executable(s) as an unprivileged user.
> >
>
> So you want the su or sudo commands?
>
> --
> Craig Ringer http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Training & Services
>

--
~Shreesha.

On 06/19/2014 01:50 AM, Shreesha wrote:

> However in my case, I don't know why there wasn't a default database
> with name 'root' got created or why the server rejects the client when
> it tries to connect to the default database.

Take a look at the initdb manual, the tutorial, and the
installation/system administration documentation.

> Can anyone shed some light on
> 1) when the default database gets created

By initdb - see the initdb manual.

> 2) how is this database 'name' is decided? Or what is the name of the
> default database name?

See the initdb manual.

> 3) Is there any other places in the database server code where this
> check is applied?

Wherever you connect, libpq picks the default database = the current
username.

> Upon looking at the error I got, I believe the code is searching for the
> database name == user name. If anyone can give some input on the code,
> it would be helpful!

libpq

I think you probably need to move this to pgsql-general, Stack Overflow,
etc. It's not really on topic for pgsql-hackers.

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

On Wed, Jun 18, 2014 at 12:50 PM, Shreesha <shreesha1988(at)gmail(dot)com> wrote:
> Well, the initdb issue looks to be resolved. Actually, after making the
> changes as suggested by Kyotaro Horiguchi, I copied only initdb binary to my
> platform and didn't copy all of them. Hence, the dependencies were still not
> resolved and was getting the error. However, now the database server is
> started and is up and running.
>
> But, When I try to connect the client to the server, I am getting the
> following error:
> ****************************************************
> /switch/pgsql/bin # ./psql
> FATAL: database "root" does not exist
> psql: FATAL: database "root" does not exist

This is easy to solve. Your database is running.

./psql postgres

you can set PGDATABASE env variable to postgres in your profile or
create a database 'root' if you want to log in without arguments. I
usually use the default postgres database as a scratch database or
administrative database to run command like creating databases.

merlin

Hello, I don't know you environment so I don't see how many
additional changes are needed, but still I think the message
should not be seen there.

> @Fabrizio de Royes Mello, Even upon making changes as per your suggestion,
> I could see that initdb is failing for the same reason:
> ********************************************************************
> /mswitch/pgsql/bin # ./initdb -D ../data/
...
> creating template1 database in ../data/base/1 ... "root" execution of the
> PostgreSQL server is not permitted.
> The server must be started under an unprivileged user ID to prevent
..
> Please let me know if I need to make changes in any other place. Appreciate
> your help!

The complaint looks to be made at the first one among the four
points I have shown, as far as I can see. Are you sure that the
'postgres' binary invoked at the time has been built after
modification? 'which postgres' will show you the file to be
checked and replaced.

| postgresql $ find . -type f -print | xargs grep -nH 'geteuid() == 0'
| ./src/backend/main/main.c:377: if (geteuid() == 0)
| ./src/bin/pg_ctl/pg_ctl.c:2121: if (geteuid() == 0)
| ./src/bin/initdb/initdb.c:778: if (geteuid() == 0) /* 0 is root's uid */
| ./src/bin/pg_resetxlog/pg_resetxlog.c:250: if (geteuid() == 0)

> On Fri, Jun 13, 2014 at 9:43 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > =?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= <fabriziomello(at)gmail(dot)com> writes:
> > > On Thu, Jun 12, 2014 at 10:59 PM, Kyotaro HORIGUCHI <
> > > horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> wrote:
> > >> Try replacing these conditions with "(0 && geteuid() == 0)" and
> > >> you would see it run as root.
> >
> > > Maybe a compile option like '--enable-run-as-root' could be added to
> > allow
> > > it without the need of change the source code.
> >
> > If we wanted it to be easy to run PG as root, those tests wouldn't be
> > there in the first place. We don't want that, so there will never be
> > anything to override that policy as easily as setting a configure option.
> >
> > In the case at hand, the OP wants to run on some weird system that
> > apparently doesn't have multiple users at all. It's a pretty safe bet
> > that hacking out those geteuid tests is just the tip of the iceberg of
> > what he's going to have to change to make it work, because it probably
> > deviates from typical-Unix-environment in a lot of other ways too.
> > So I can't get too concerned about how easy this one aspect is for him.

--
Kyotaro Horiguchi
NTT Open Source Software Center