Re: [HACKERS] [PATCH] get_home_path: use HOME

[Daniel Verite]

Tom Lane wrote:

> If we take this patch, what's to stop someone from complaining that we
> broke *their* badly-designed system that abuses the HOME variable?

POSIX warns against doing that, listing HOME in the variables that
should be left to their intended usage:
http://pubs.opengroup.org/onlinepubs/9699919799/


  If the variables in the following two sections are present in the
  environment during the execution of an application or utility, they
  shall be given the meaning described below
  [...]
  HOME
  The system shall initialize this variable at the time of login to
  be a pathname of the user's home directory. See .


psql is indirectly using $HOME already for readline and terminfo:

$ HOME=/tmp/home2 strace psql 2>tr ; grep home2 tr
...
stat("/tmp/home2/.terminfo", 0x7ff985bf4730) = -1 ENOENT (No such file or
directory)
stat("/tmp/home2/.inputrc", 0x7fff3f641d70) = -1 ENOENT (No such file or
directory)

Also when using Debian's psql, the wrapper looks for it own config file in
$HOME:
open("/tmp/home2/.postgresqlrc", O_RDONLY) = -1 ENOENT (No such file or
directory)
Being written in Perl, it could use getpwuid(), but it doesn't, like I
believe
the majority of programs that just want the home directory.

+1 on using HOME for being consistent with other pieces of code around
postgres, and for the easiness of locally overriding it when
troubleshooting problems with dot files.


Best regards,
-- 
Daniel Vérité
PostgreSQL-powered mailer: http://www.manitou-mail.org
Twitter: @DanielVerite


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [PATCH] get_home_path: use HOME

[Peter Eisentraut]

On 9/20/16 1:44 PM, Rudolf Gavlas wrote:
> If you think that using the value of HOME variable as the user's home
> directory is bad idea, I won't argue with that, I've already expressed
> my opinion. What is the real problem here is using home directory of a
> user A as a home directory for user B. That's clearly a bug and if you
> want to solve it without using HOME, I am fine with that.

I have no problem with using the HOME variable optionally.  That is
wide-spread practice.  But I dispute what you describe as the "real
problem".  In Unix, users are identified by uids.  The real problem, as
I see it, is that you think you have multiple users but you actually don't.

-- 
Peter Eisentraut  http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [PATCH] get_home_path: use HOME

[Aleksander Alekseev]

> I work in an environment, where servers are administered by people
> with different user names and identical uid (0).

Multiple users with same uid is orthodox indeed. Just out of curiosity -
what environment is this, if it's not a secret?

> The usage of HOME environment variable (if set) is IMO the right,
> standard and faster way to get_home_path().

As a side note I personally think that considering $HOME environment
variable is not such a bad idea. However I think we should make sure
first that this is really a bug that is relatively easy to reproduce in
real-world environments, a not just a hack for single misconfigured
system.

-- 
Best regards,
Aleksander Alekseev


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [PATCH] get_home_path: use HOME

[Rudolf Gavlas]

2016-09-20 18:35 GMT+02:00, Tom Lane :
> Rudolf Gavlas  writes:
>> The usage of HOME environment variable (if set) is IMO the right,
>> standard and faster way to get_home_path().
>
> Can you provide some evidence for that claim?  I can believe "faster"
> but the rest sounds like wishful thinking.

1) NetBSD glob(3)
http://netbsd.gw.com/cgi-bin/man-cgi?glob+3+NetBSD-current
ENVIRONMENT
HOME  If defined, used as the home directory of the current user in
tilde expansions.

2) BIND
https://nxr.netbsd.org/xref/src/external/bsd/bind/dist/bin/dig/dig.c#1765

3) less
https://nxr.netbsd.org/xref/src/external/bsd/less/dist/cmdbuf.c#1403
(https://nxr.netbsd.org/xref/src/external/bsd/less/dist/decode.c#533)

4) NetBSD sh(1)
http://netbsd.gw.com/cgi-bin/man-cgi?sh+1+NetBSD-current
ENVIRONMENT
HOME  Set automatically by login(1) from the user's login directory in
the password file (passwd(5)).  This environment variable also
functions as the default argument for the cd built-in.

5) bash(1) (version 4.3.39)
Shell Variables
The following variables are used by the shell.  In some cases, bash
assigns a default value to a variable; these cases are noted below.
HOME   The home directory of the current user; the default argument
for the cd builtin command.  The value of this variable is also used
when performing tilde expansion.

6) OpenLDAP
https://nxr.netbsd.org/xref/src/external/bsd/openldap/dist/libraries/libldap/init.c#331

I've just grabbed what I have at hand, the list could go on ...

>> I work in an environment, where servers are administered by people
>> with different user names and identical uid (0).
>
> I think what you have there is an incredibly badly-designed system that
> can be expected to break outside software (eg, Postgres).  If we take
> this patch, what's to stop someone from complaining that we broke *their*
> badly-designed system that abuses the HOME variable?  I'm pretty hesitant
> to touch code that's worked the same way for a decade or two on such a
> basis.

I don't think this system is incredibly bad. But that's off-topic.

If you think that using the value of HOME variable as the user's home
directory is bad idea, I won't argue with that, I've already expressed
my opinion. What is the real problem here is using home directory of a
user A as a home directory for user B. That's clearly a bug and if you
want to solve it without using HOME, I am fine with that.

r.


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [PATCH] get_home_path: use HOME

[Rudolf Gavlas]

2016-09-20 18:55 GMT+02:00, Alvaro Herrera :
> Rudolf Gavlas wrote:
>
>> I work in an environment, where servers are administered by people
>> with different user names and identical uid (0).
>
> So everyone is superuser there?  That sounds, um, unorthodox.

Yes, the administrators of the servers, that means people responsible
for installing, configuring and running all of the software on the
servers day and night are superusers there. I am quite surprised it
may sound unorthodox. I am only used to unix environment though. What
is the orthodox way of doing that, btw?

r.


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [PATCH] get_home_path: use HOME

[Alvaro Herrera]

Rudolf Gavlas wrote:
> 2016-09-20 18:55 GMT+02:00, Alvaro Herrera :
> > Rudolf Gavlas wrote:
> >
> >> I work in an environment, where servers are administered by people
> >> with different user names and identical uid (0).
> >
> > So everyone is superuser there?  That sounds, um, unorthodox.
> 
> Yes, the administrators of the servers, that means people responsible
> for installing, configuring and running all of the software on the
> servers day and night are superusers there. I am quite surprised it
> may sound unorthodox. I am only used to unix environment though. What
> is the orthodox way of doing that, btw?

In my view of the world, each of the admins would have a regular user,
with the privilege of running commands as superuser using something like
"sudo" (including running a shell).

get_home_path is psql's code.  I would expect client connections to come
from regular users, as it is considered risky to run all code with
elevated privileges, anyway.

As I recall, if you tried to start the postgres server using a superuser
account you would quickly find out that it completely refuses to start.
I suppose it works because some start script su's to the postgres
unprivileged account to run pg_ctl.  (Windows is an exception to this,
where it used to be customary to run servers using administrator
privileges, where instead of outright refusing to run, pg_ctl would drop
all privileges first.)

-- 
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [PATCH] get_home_path: use HOME

[Alvaro Herrera]

Rudolf Gavlas wrote:

> I work in an environment, where servers are administered by people
> with different user names and identical uid (0).

So everyone is superuser there?  That sounds, um, unorthodox.

-- 
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [PATCH] get_home_path: use HOME

[Tom Lane]

Rudolf Gavlas  writes:
> The usage of HOME environment variable (if set) is IMO the right,
> standard and faster way to get_home_path().

Can you provide some evidence for that claim?  I can believe "faster"
but the rest sounds like wishful thinking.

> I work in an environment, where servers are administered by people
> with different user names and identical uid (0).

I think what you have there is an incredibly badly-designed system that
can be expected to break outside software (eg, Postgres).  If we take
this patch, what's to stop someone from complaining that we broke *their*
badly-designed system that abuses the HOME variable?  I'm pretty hesitant
to touch code that's worked the same way for a decade or two on such a
basis.

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] [PATCH] get_home_path: use HOME

[Rudolf Gavlas]

Hi,

I work in an environment, where servers are administered by people
with different user names and identical uid (0). The attached patch
fixes a bug exposed in such environments: where the logic of
retrieving a personal configuration file relies solely on
get_home_path(), the different users are forced to share the file of
the first user with given uid.

The usage of HOME environment variable (if set) is IMO the right,
standard and faster way to get_home_path().

r.
diff --git a/src/port/path.c b/src/port/path.c
index 7bf7cbc..33cb790 100644
--- a/src/port/path.c
+++ b/src/port/path.c
@@ -807,15 +807,24 @@ bool
 get_home_path(char *ret_path)
 {
 #ifndef WIN32
-	char		pwdbuf[BUFSIZ];
-	struct passwd pwdstr;
-	struct passwd *pwd = NULL;
-
-	(void) pqGetpwuid(geteuid(), , pwdbuf, sizeof(pwdbuf), );
-	if (pwd == NULL)
-		return false;
-	strlcpy(ret_path, pwd->pw_dir, MAXPGPATH);
-	return true;
+	char		*envhome = getenv("HOME");
+	if (envhome != NULL && strlen(envhome) > 0)
+	{
+		strlcpy(ret_path, envhome, MAXPGPATH);
+		return true;
+	}
+	else
+	{
+		char		pwdbuf[BUFSIZ];
+		struct passwd pwdstr;
+		struct passwd *pwd = NULL;
+
+		(void) pqGetpwuid(geteuid(), , pwdbuf, sizeof(pwdbuf), );
+		if (pwd == NULL)
+			return false;
+		strlcpy(ret_path, pwd->pw_dir, MAXPGPATH);
+		return true;
+	}
 #else
 	char	   *tmppath;
 

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers