On Tue, Oct 18, 2016 at 03:27:46PM +0100, Steve McIntyre wrote:
> The code, well...
>       if (process.platform === 'linux') {
>               return home || (process.getuid() === 0 ? '/root' : (user ? 
> '/home/' + user : null));
>       }
> Things are more complicated than that. What exactly is this code meant
> to be used for?

This is so wrong, I would like to ask that this package not be allowed
into Debian until it's fixed.

A user's home directory in Unix is recorded in /etc/passwd, or in a
similar record accessed via a directory service of some kind. The
standard C library call for retrieving that information is getpwuid
(see manual page for details of usage). Note that reading /etc/passwd
directly is also not acceptable, you really do need to use the
standard interface (getpwuid) to get this right.

There is NO guarantee that root's home directory on a Unix system is
/root. /root might not even exist. Even if it exists, it might be
someone else's home directory. User foo's home directory might be
anywhere on the filesystem. It is true that on most Linux systems
/root is root's home directory, and /home/foo is foo's home directory,
but there are no guarantees whatsoever that this is actually true. If
you make this assumption, your code will break.

The FHS specifies /root as root's home directory, and /home where home
directories go, but the local sysadmin can override all of that. Also,
the local sysadmin can impose a hierarchy inside /home, and some do,
particularly on large sites.

Hardcoding assuptions like the code snippet above does is not just a
little buggy, it's a potential security problem. It is not infrequent
that a program needs to access files in a user's home directory, and
if it looks in the wrong place, that opens up an exploitable bug. If
you assume /root is root's home directory, and it's actually someone
else's directory, and you trust /root/.ssh/authorized_keys is root's
authorized ssh keys, you're going to have a bad time.

Trusting $HOME can be similarly dangerous for anything security
sensitive, but at least it is not quite as silly as hardcoding
assumptions in code.

I want to build worthwhile things that might last. --joeyh

Attachment: signature.asc
Description: PGP signature

Reply via email to