From: | Anders Kaseorg <andersk(at)mit(dot)edu> |
---|---|
To: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, alvherre(at)alvh(dot)no-ip(dot)org |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: [PATCH] Prefer getenv("HOME") to find the UNIX home directory |
Date: | 2021-10-19 09:44:03 |
Message-ID: | 5d675cbe-7837-e9ae-961d-be7d03201f3b@mit.edu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
Anders
From | Date | Subject | |
---|---|---|---|
Next Message | Ronan Dunklau | 2021-10-19 09:51:40 | Re: Delegating superuser tasks to new security roles (Was: Granting control of SUSET gucs to non-superusers) |
Previous Message | Zhihong Yu | 2021-10-19 09:12:46 | Re: UPDATE on Domain Array that is based on a composite key crashes |