#2183 tcl_platform(user) is spoofable

obsolete: 8.4.1
Don Porter

It seems that on Unix, that value of
tcl_platform(user) is simply copied over
from env(USER) or env(LOGNAME).
There doesn't seem to be any attempt
to discover and report the actual
uid under which the process is running.

On Windows, the value is taken first
from env(USERNAME), and a call
to GetUserName() takes place only
if env(USERNAME) is not set.

This is a bit troubling. Tcl already provides
access to the environment variables
via the env array, so there's really
nothing new provided. However, because
the value is placed in tcl_platform(user)
it gains the color of authority as a value
provded by Tcl iteself, distinguished
from the env variable values, which any
programmer knows can be set by the
end user.

Anyone programmer trusting tcl_platform(user)
to be truthful is acting on misplaced faith.
The existence of tcl_platform(user) encourages
such inappropriate trust.


  • Donal K. Fellows

    Logged In: YES

    Hmm. Is this a call to use getpwuid(getuid()) on UNIX?
    (Which probably needs thread-protection too. I'd be
    startled if getpwuid was reentrant normally...)

  • Don Porter

    Don Porter - 2003-05-13

    Logged In: YES

    not really, but it is part of a larger
    observation that the contents of the
    tcl_platform are losing their coherence.

    the name "tcl_platform" suggests
    information about the platform on
    which the program is running, and
    most elements do that: platform,
    machine, os, osVersion, byteOrder,
    and wordSize.

    tcl_platform has added (sometimes) the elements
    threaded and/or debug, which really tell
    you about the variant of the Tcl library
    itself, not something about the platform.
    Data that would be better in something like
    tcl::config or [package about Tcl].

    Finally, we have tcl_platform(user), which
    turns out to just be an alternative name for
    the variable env(USER). It has nothing to
    do with the platform, it duplicates something
    we already had, and because of that duplication,
    suggests the possibility of greater authority that
    isn't really there. All (potential) confusion, and
    nearly zero utility.

    *If* tcl_platform(user) were connected to the
    getuid() call, at least then I could defend it as
    a poor interface to useful information. Looks like
    a complete mistake as is.

  • Donal K. Fellows

    Logged In: YES

    Here's a simple basic patch. Any reason why this isn't
    sufficient (possibly after hacking around with autoconf and
    moving the #includes to tclInt.h, of course.)

  • Donal K. Fellows

    Logged In: YES

    Oops. Inverted test sense and forgot to convert encodings.
    Try this fixed version.

  • Donal K. Fellows

    fixed version

  • Donal K. Fellows

    Logged In: YES

    Problem: Code is not thread-safe and probably not possible
    to make thread-safe (not all platforms have getpwuid_r);
    perhaps a mutex lock would help?

  • David N. Welton

    David N. Welton - 2005-04-30

    Logged In: YES


    The fact that it is going after USER and LOGNAME env
    variables is also problematic in environments where those
    are not set. I just spent a couple of hours chasing down a
    bug in tcllib's mime smtp package which turns out to be
    related to the fact that under Apache, those variables are
    not set, and so tcl_platform(user) is empty. I think that
    looking at getpwuid is far better than leaving this empty.


  • Donal K. Fellows

    Logged In: YES
    Originator: NO

    Fixed in HEAD.

  • Donal K. Fellows

    • assigned_to: dgp --> dkf
    • status: open --> closed-fixed

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks