Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SR-437] fatalError - could not get correct login name #4184

Closed
drewcrawford opened this issue Jan 2, 2016 · 5 comments
Closed

[SR-437] fatalError - could not get correct login name #4184

drewcrawford opened this issue Jan 2, 2016 · 5 comments

Comments

@drewcrawford
Copy link
Contributor

Previous ID SR-437
Radar None
Original Reporter @drewcrawford
Type Bug
Status Closed
Resolution Done
Environment

Linux x86_64 (glibc)
swift-2.2-SNAPSHOT-2015-12-31-a

Additional Detail from JIRA
Votes 0
Component/s Foundation
Labels Bug
Assignee Eugene Gubin (JIRA)
Priority Medium

md5: e1a9699af115cfcb14b4871015c130ae

Issue Description:

This is a bug in swift-corelibs-foundation; it's a regression new in the dec-31 snapshot. You cannot run buildbot_linux without a TTY attached (for example, in a Docker container).

The root cause is the implementation of NSUserName, which is exercised in a test suite and will crash without a TTY.

The actual root cause is that getlogin(_r) does not work without a TTY due to a glibc bug.
According to the the manpage, getlogin_r call can fail if:

Standard input didn't refer to a terminal. (See BUGS.)

It goes on to explain:

Unfortunately, it is often rather easy to fool getlogin(). Sometimes it does not work at all, because some program messed up the utmp file. Often, it gives only the first 8 characters of the login name. The user currently logged in on the controlling terminal of our program need not be the user who started it. Avoid getlogin() for security-related purposes.

Note that glibc does not follow the POSIX specification and uses stdin instead of /dev/tty. A bug. (Other recent systems, like SunOS 5.8 and HP-UX 11.11 and FreeBSD 4.8 all return the login name also when stdin is redirected.)

This glibc bug occurs in real-world scenarios:

1. This call is exercised in a test that runs under buildbot_linux
2. I build buildbot_linux inside a Docker container
3. Docker containers have no attached tty during a build
4. The swift-2.2-SNAPSHOT-2015-12-31-a can no longer be built for Docker.

The bug can be reproduced (although it takes awhile) on any system with Docker installed by creating a file called 'Dockerfile' with the following contents and then running "docker build ."

    FROM debian:latest

    ENV SWIFT_TAG="swift-2.2-SNAPSHOT-2015-12-31-a" RUNTIME_PACKAGES="clang libedit2 libpython2.7 libxml2 libicu52" BUILDTIME_PACKAGES="git ca-certificates python ninja-build cmake uuid-dev libbsd-dev libicu-dev pkg-config libedit-dev file libxml2-dev python-dev libncurses5-dev libsqlite3-dev libreadline6-dev rsync"

    RUN \
    # Create a directory to work in \
    mkdir swift-dev && \
    cd swift-dev && \
    # Install the runtime and build-time dependencies \
    apt-get update && \
    apt-get install $RUNTIME_PACKAGES $BUILDTIME_PACKAGES -y --no-install-recommends && \
    \
    git clone https://github.com/apple/swift.git && \
    cd swift && \
    # submodules?  Where we're going, we don't need submodules! \
    ./utils/update-checkout --clone && \
    \
    # The silly update-checkout script does not understand matching the swift checkout ref \
    # In practice what you're supposed to do (I think!  It's not documented!) is check out the same snapshot tag  \
    # Not all the folders have them (where do some of them come from??) but we'll just try them all \
    find ../ -maxdepth 1 -type d  -exec bash -c '(cd {} && echo checking out in `pwd` && git checkout $SWIFT_TAG)' \; && \
    \
    # And now we build, like a good little linuxen. \
    # I believe this is what the linux build script does.  In practice, this builds a system into /tmp/install and then tars it up. \
    ./utils/build-script --preset=buildbot_linux install_destdir="/tmp/install" installable_package="/tmp/swift.tar.gz" && \
    \
    # Install our tarball to /usr/local \
    tar xf /tmp/swift.tar.gz -C /usr/local --strip-components 1 && \
    \
    # Clean up \
    cd / && \
    rm -rf /tmp/swift.tar.gz /swift-dev && \
    apt-get remove --purge -y $BUILDTIME_PACKAGES && \
    apt-get autoremove --purge -y && \
    apt-get clean -y && \
    apt-get autoclean -y && \
    rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*

    ENTRYPOINT ["bash"]

This produces a "fatalError - could not get login name" with errno ENOTTY.

It's not immediately clear how to fix this so I'm pinging the implementor of NSUserName.

@drewcrawford
Copy link
Contributor Author

I currently work around with this patch.

It's obviously not a proper solution but it does let me build again with Docker.

@phausler
Copy link
Member

phausler commented Jan 2, 2016

Hmm "Jeff" might not be a good default return value here; perhaps "" or "unknown" etc might be a bit more appropriate and less confusing. We may want to also consider reducing the unit test scope for non TTY enabled sessions and skip certain tests when that is the case

@swift-ci
Copy link
Contributor

swift-ci commented Jan 2, 2016

Comment by Eugene Gubin (JIRA)

#206 I made some improvements. Mentioned workaround in place. I think PR should be tested with and without it.

@drewcrawford
Copy link
Contributor Author

I think this is resolved in PR #206, now merged. Thanks Eugene Gubin (JIRA User)!

@drewcrawford
Copy link
Contributor Author

Tested by me

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
@shahmishal shahmishal transferred this issue from apple/swift May 5, 2022
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants