Opened 9 years ago

Closed 6 years ago

#970 closed defect (invalid)

[kean] noisy traceback when piping into bindctl without login

Reported by: jreed Owned by: kean
Priority: medium Milestone: Sprint-20131015
Component: ~bind-ctl (obsolete) Version:
Keywords: Cc:
CVSS Scoring: Parent Tickets:
Sensitive: no Defect Severity: Medium
Sub-Project: DNS Feature Depending on Ticket:
Estimated Difficulty: 0.0 Add Hours to Ticket: 0
Total Hours: 0 Internal?: no


I often just pipe commands into bindctl.

But one from a different login I didn't have ~/.bind10 readable. This caused bindctl to have noisy traceback output. It prompted me multiple times on same line and when I pressed enter:

(11:09:57) jreed: Username:Traceback (most recent call last):
  File "/home/jreed/opt/bind10/bin/bindctl", line 138, in <module>
  File "/var/users/jreed/opt/bind10/lib/python3.1/site-packages/bindctl/", line 125, in run
    if not self.login_to_cmdctl():
  File "/var/users/jreed/opt/bind10/lib/python3.1/site-packages/bindctl/", line 213, in login_to_cmdctl
    username = input("Username:")
EOFError: EOF when reading a line

The initial problem is that the ~/.bind10 directory was created in the wrong users home. I earlier ran as root and so root shouldn't have created it in regular user's home. (Maybe this should be two different tickets.)


Change History (6)

comment:1 Changed 9 years ago by shane

  • Defect Severity changed from N/A to Medium
  • Milestone changed from New Tasks to Year 3 Task Backlog

comment:2 Changed 6 years ago by muks

  • Milestone set to Sprint-20130903
  • Summary changed from noisy traceback when piping into bindctl without login to [kean] noisy traceback when piping into bindctl without login

comment:3 Changed 6 years ago by kean

  • Owner set to kean
  • Status changed from new to accepted

comment:4 Changed 6 years ago by kean

  • Owner changed from kean to UnAssigned
  • Status changed from accepted to reviewing

This is another old bug that no longer seems to exist. I changed the ownership of my home directory .bind10 to root and ran bindctl:

Error reading saved username and password from /home/kean/.bind10/default_user.csv: [Errno 13] Permission denied: '/home/kean/.bind10/default_user.csv'

No stored password file found.

When the system is first set up you need to create at least one user account.
For information on how to set up a BIND 10 system, please check see the
BIND 10 Guide:

If a user account has been set up, please check the b10-cmdctl log for other

Username: kean
["login success"]
Error saving user information: [Errno 13] Permission denied: '/home/kean/.bind10/default_user.csv'
user info file name: /home/kean/.bind10/default_user.csv

I then removed the .bind10 directory, became root via su and re-ran bind10 and bindctl. The .bind10 directory was correctly created in the root user's home directory, not in my directory.

The code that decides where to put the directory looks like this:

self.csv_file_dir = pwd.getpwnam(getpass.getuser()).pw_dir + \
    os.sep + '.bind10' + os.sep

According to the Python docs for getpass.getuser: "This function checks the environment variables LOGNAME, USER, LNAME and USERNAME, in order, and returns the value of the first one which is set to a non-empty string. If none are set, the login name from the password database is returned on systems which support the pwd module, otherwise, an exception is raised."

Certainly on Linux Fedora Core 19, after doing an su all of those variables except for USERNAME are all set to "root". Only USERNAME retians my original login. The bug did not specify which platform this was for but I suspect that on that platform LOGNAME or USER remained set to the original user name. The error is one of usage of su. It is considered good practice to do an "su -" so that the session acts as if it had just started up (and would therefore set the environment as if the real root user had logged in) rather than just changing the euid to 0, as happens with certain implementations of su.

Regardless, the code above is correct (although perhaps overly complicated - it could probably just as easily use $HOME rather than bothering with parsing the passwd entries) and so my analysis of this bug is that it is simply no longer valid and requires no changes.

comment:5 Changed 6 years ago by muks

  • Owner changed from UnAssigned to kean

Verified that there is no longer any traceback. An error message is printed on the console instead which includes the reason (permission denied).

Please go ahead and resolve this ticket.

comment:6 Changed 6 years ago by kean

  • Resolution set to invalid
  • Status changed from reviewing to closed
Note: See TracTickets for help on using tickets.