Re: security risk in source builtin?

[Phil Pennock <phil.pennock@xxxxxxxxxxx>]

On 2003-09-17 at 09:35 +0200, Dominik Vogt wrote:
> I may have confused the test cases for bash and zsh.  Thanks for
> pointing that out.  However, that does not change my concern that
> "source" (as well as ".") is a security risk.

Could you please explain how it's a security risk?  I think I'm missing
something.

My viewpoint is based around the idea that when I type a command-name,
a process is started running from a program stored somewhere in $PATH,
and runs with all my access rights.  So if someone untrusted can write
to somewhere in $PATH then execlp()/execvp() become dangerous and most
of Unix suddenly has security holes.

Don't add directories to $PATH unless you absolutely trust everyone who
can write to that directory, or move it aside somewhere up the
filesystem tree, or can write to a file in that directory.

Hence the presence of "." as an element of $PATH (or the equivalent
empty element, indicated by double, leading or trailing colons) is a
very dubious practice.  And using "source" is dubious, unless you're
very sure of where you are.

I've trained myself to use ". ./filename" so that at least it's explicit
that I know that it's the current directory.

Now, if the modern ACL and MAC unices have a way for executables to
inherit privilege-dropping flags from a directory, so that a directory
can be flagged so that all executables within it automatically revoke
some set of privileges, _then_ having "source"/"." use the same $PATH
becomes an issue.  But AFAIK, none of the systems about support this
sort of inheritance of extended attributes (I could well be wrong).
-- 
2001: Blogging invented. Promises to change the way people bore strangers with
banal anecdotes about their pets. <http://www.thelemon.net/issues/timeline.php>