Thread: [PATCH] get_home_path: use HOME
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.
Attachment
Rudolf Gavlas <r.stu3.1@googlemail.com> 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
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 Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Rudolf Gavlas wrote: > 2016-09-20 18:55 GMT+02:00, Alvaro Herrera <alvherre@2ndquadrant.com>: > > 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 Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
2016-09-20 18:35 GMT+02:00, Tom Lane <tgl@sss.pgh.pa.us>: > Rudolf Gavlas <r.stu3.1@googlemail.com> 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.
2016-09-20 18:55 GMT+02:00, Alvaro Herrera <alvherre@2ndquadrant.com>: > 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.
> 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
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
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/ <quote> If the variables in the following two sections are present in the environment during the execution of an applicationor utility, they shall be given the meaning described below [...] HOME The system shall initialize this variableat the time of login to be a pathname of the user's home directory. See <pwd.h>. </quote> 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