Re: BUG #15120: use of getcwd(3)/chdir(2) during path resolution (exec.c)
От | Tom Lane |
---|---|
Тема | Re: BUG #15120: use of getcwd(3)/chdir(2) during path resolution (exec.c) |
Дата | |
Msg-id | 7607.1521309974@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #15120: use of getcwd(3)/chdir(2) during path resolution (exec.c) (Andrew Gierth <andrew@tao11.riddles.org.uk>) |
Ответы |
Re: BUG #15120: use of getcwd(3)/chdir(2) during path resolution (exec.c)
|
Список | pgsql-bugs |
Andrew Gierth <andrew@tao11.riddles.org.uk> writes: > "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes: > Tom> ... I find that quite an unacceptable answer. We need to resolve > Tom> the symlink correctly, or we risk malfunctioning later, for the > Tom> reasons recited in the comment for find_my_exec(). > On systems with openat(), would it not be possible to resolve symlinks > without ever needing chdir? Um ... AFAICS, openat() just opens a file, it doesn't give back a resolved path. Did you mean readlinkat()? In any case, we'd still need to support logic that doesn't rely on non-portable functions. The (vague) idea I had was to try a little harder to build absolute paths for ourselves instead of letting the system do it. I believe for instance that canonicalize_path() has more smarts now about shortening paths like /foo/bar/baz/../../quux than it did when these functions were written, so we might be able to rely on just concatenating paths and then canonicalizing the result. (OTOH, I think there are filesystems where this wouldn't necessarily yield a nice answer, due to multiple mounts and suchlike.) regards, tom lane
В списке pgsql-bugs по дате отправления: