Обсуждение: abort()/segfault when starting postgres in inaccessible CWD

Hi,

Starting postgres with a CWD that's not readable will trigger an Assert
and if those are disabled it presumably will segfault.

#0  0x00007ffff75621e5 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x00007ffff7565398 in __GI_abort () at abort.c:90
#2  0x000000000089031d in ExceptionalCondition (
    conditionName=0xa6e530 "!(((CurrentMemoryContext) != ((void *)0) && (((((const
Node*)((CurrentMemoryContext)))->type)== T_AllocSetContext))))", errorType=0xa6e2c9 "BadArgument", fileName=0xa6e240
"/home/andres/src/postgresql/src/backend/utils/mmgr/mcxt.c",lineNumber=649) 
    at /home/andres/src/postgresql/src/backend/utils/error/assert.c:54
#3  0x00000000008bc206 in palloc (size=1024) at /home/andres/src/postgresql/src/backend/utils/mmgr/mcxt.c:649
#4  0x00000000006597b2 in initStringInfo (str=0x7fffffffc410) at
/home/andres/src/postgresql/src/backend/lib/stringinfo.c:50
#5  0x0000000000896383 in expand_fmt_string (fmt=0xa8d3e8 "could not change directory to \"%s\": %s", edata=0xd587e0
<errordata>)
    at /home/andres/src/postgresql/src/backend/utils/error/elog.c:3167
#6  0x0000000000892c52 in elog_finish (elevel=15, fmt=0xa8d3e8 "could not change directory to \"%s\": %s")
    at /home/andres/src/postgresql/src/backend/utils/error/elog.c:1297
#7  0x00000000008d932a in resolve_symlinks (path=0x7fffffffdad0
"/home/andres/build/postgres/dev-assert/vpath/src/backend/postgres")
    at /home/andres/src/postgresql/src/port/exec.c:293
#8  0x00000000008d8e10 in find_my_exec (argv0=0xd60bb0
"/home/andres/build/postgres/dev-assert/vpath/src/backend/postgres", 
    retpath=0x7fffffffdad0 "/home/andres/build/postgres/dev-assert/vpath/src/backend/postgres")
    at /home/andres/src/postgresql/src/port/exec.c:144
#9  0x00000000008d96aa in set_pglocale_pgservice (argv0=0xd60bb0
"/home/andres/build/postgres/dev-assert/vpath/src/backend/postgres", 
    app=0xa05440 "postgres-9.4") at /home/andres/src/postgresql/src/port/exec.c:561
#10 0x0000000000668932 in main (argc=21, argv=0xd60af0) at /home/andres/src/postgresql/src/backend/main/main.c:98

So, the problem is that we're calling set_pglocale_pgservice() which
indirectly can call elog() long before we've initialized memory
contexts.

To reproduce do something like:

# become root
su
# change into root-only directory
cd /root
# switch user, without changing directory
su postgres
# execute postgres
/path/to/postgres -D frakbar

Greetings,

Andres Freund

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

Andres Freund <andres@2ndquadrant.com> writes:
> Starting postgres with a CWD that's not readable will trigger an Assert
> and if those are disabled it presumably will segfault.

Yeah, we've discussed that before.  I'm not sure it's worth fixing,
or that it could be counted on to stay fixed even if we removed the
current source(s) of trouble.

There's a bigger problem with the scenario you show, which is that the
postmaster is started with root's environment variables not postgres'.
That's likely to lead to assorted surprises that we can't really do
anything about, even if we fixed the CWD issue.  So I'm inclined to think
this scenario is a "don't do that".

Having said that, though, it seems like a bad idea to be calling
set_pglocale_pgservice() before palloc is functional.  It's not at all
obvious that that function can't be allowed to use palloc.

            regards, tom lane

On 2013-10-03 19:07:37 +0200, Tom Lane wrote:
> Andres Freund <andres@2ndquadrant.com> writes:
> > Starting postgres with a CWD that's not readable will trigger an Assert
> > and if those are disabled it presumably will segfault.
>
> Yeah, we've discussed that before.  I'm not sure it's worth fixing,
> or that it could be counted on to stay fixed even if we removed the
> current source(s) of trouble.
>
> There's a bigger problem with the scenario you show, which is that the
> postmaster is started with root's environment variables not postgres'.
> That's likely to lead to assorted surprises that we can't really do
> anything about, even if we fixed the CWD issue.  So I'm inclined to think
> this scenario is a "don't do that".

I have no problem not supporting the scenario of an inaccessible CWD -
I'd just like to have a better error message than a segfault...

> Having said that, though, it seems like a bad idea to be calling
> set_pglocale_pgservice() before palloc is functional.  It's not at all
> obvious that that function can't be allowed to use palloc.

Yes, and it seems hard to control - as proven here - that it doesn't
make any calls to functions using palloc() in some edge cases.

Greetings,

Andres Freund

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