Code

Opened 7 years ago

Closed 6 years ago

Last modified 6 years ago

#5753 closed (fixed)

manage syncdb (first time) in a small chrooted environment for example don't give defaultuser...

Reported by: ClaesBas Owned by: nobody
Component: Uncategorized Version: master
Severity: Keywords: syncdb superuser
Cc: Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description

What a about this patch?

Index: django/contrib/auth/create_superuser.py
===================================================================
--- django/contrib/auth/create_superuser.py     (revision 6507)
+++ django/contrib/auth/create_superuser.py     (working copy)
@@ -22,7 +22,10 @@
         default_username = ''
     else:
         # Determine the current system user's username, to use as a default.
-        default_username = pwd.getpwuid(os.getuid())[0].replace(' ', '').lower()
+        try:
+            default_username = pwd.getpwuid(os.getuid())[0].replace(' ', '').lower()
+        except KeyError:
+            default_username = 'admin'
 
     # Determine whether the default username is taken, so we don't display
     # it as an option.

Attachments (0)

Change History (4)

comment:1 Changed 7 years ago by mtredinnick

  • Has patch unset
  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Accepted

[For other readers wondering what this is about: if you have a really minimal environ with no auth support, then getuid() may fail to return a username. This usually means you need at least /etc/passwd.]

I would think there's going to be a fair bit of stuff that will cause problems if there's no /etc/passwd or other way for things like getuid() to work, so you're not really solving the root problem here. Still, it's probably a relatively harmless fix, but it needs a comment about why it can fail.

I'd probably prefer that we just didn't display a default username in this case, too, if we go down this path.

In future, please give an explanation of what you're trying to fix. I've had enough experience with setting up chroot environments to recognise the problem, but not everybody is going to have been that unlucky in the past and you really are talking about a far-out edge case here.

comment:2 Changed 6 years ago by mtredinnick

  • Resolution set to fixed
  • Status changed from new to closed

(In [9158]) Fixed #5753 -- Allow createsuperuser to work in situations where there
might be a valid password database entry for the current user id.

comment:3 Changed 6 years ago by mtredinnick

(In [9159]) [1.0.X] Fixed #5753 -- Allow createsuperuser to work in situations where there
might be a valid password database entry for the current user id.

Backport of r9158 from trunk.

comment:4 Changed 6 years ago by mtredinnick

Since there are situations where normal usage or Django (using "createsuperuser") could lead to a crash before this change, I decided to also commit it on the branch. If it causes any trouble, though, we could safely remove it from there. It's pretty borderline, as indicated in my first comment on this ticket.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.