From: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
---|---|
To: | andersk(at)mit(dot)edu |
Cc: | alvherre(at)alvh(dot)no-ip(dot)org, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: [PATCH] Prefer getenv("HOME") to find the UNIX home directory |
Date: | 2021-10-20 05:40:14 |
Message-ID: | 20211020.144014.580443822870543857.horikyota.ntt@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
At Tue, 19 Oct 2021 02:44:03 -0700, Anders Kaseorg <andersk(at)mit(dot)edu> wrote in
> On 10/19/21 01:34, Kyotaro Horiguchi wrote:
> > I tend to agree to this, but seeing ssh ignoring $HOME, I'm not sure
> > it's safe that we follow the variable at least when accessing
> > confidentiality(?) files. Since I don't understand the exact
> > reasoning for the ssh's behavior so it's just my humbole opinion.
>
> According to https://bugzilla.mindrot.org/show_bug.cgi?id=3048#c1, it
> used to be supported to install the ssh binary as setuid. A
> setuid/setgid binary needs to treat all environment variables with
> suspicion: if it can be convinced to write a file to $HOME with root
> privileges, then a user who modifies $HOME before invoking the binary
> could cause it to write to a file that the user normally couldn’t.
>
> There’s no such concern for a binary that isn’t setuid/setgid. Anyone
> with the ability to modify $HOME can be assumed to already have full
> control of the user account.
Thansk for the link. Still I'm not sure it's the fact but it sounds
reasonable enough. If that's the case, I vote +1 for psql or other
commands honoring $HOME.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
From | Date | Subject | |
---|---|---|---|
Next Message | tanghy.fnst@fujitsu.com | 2021-10-20 06:04:16 | RE: Added schema level support for publication. |
Previous Message | Michael Paquier | 2021-10-20 05:39:01 | Re: TAP test for recovery_end_command |