Django

Code

Ticket #5753 (closed: fixed)

Opened 1 year ago

Last modified 2 months ago

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

Reported by: ClaesBas Assigned to: nobody
Milestone: Component: Uncategorized
Version: SVN Keywords: syncdb superuser
Cc: Triage Stage: Accepted
Has patch: 0 Needs documentation: 0
Needs tests: 0 Patch needs improvement: 0

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

Change History

10/14/07 13:13:32 changed by mtredinnick

  • needs_better_patch changed.
  • has_patch deleted.
  • stage changed from Unreviewed to Accepted.
  • needs_tests changed.
  • needs_docs changed.

[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.

10/05/08 23:54:15 changed by mtredinnick

  • status changed from new to closed.
  • resolution set to fixed.

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

10/05/08 23:56:51 changed 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.

10/05/08 23:58:19 changed 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/Change #5753 (manage syncdb (first time) in a small chrooted environment for example don't give defaultuser...)




Change Properties
Action