Opened 16 years ago

Closed 15 years ago

Last modified 15 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: dev
Severity: Keywords: syncdb superuser
Cc: Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

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.

Change History (4)

comment:1 by Malcolm Tredinnick, 16 years ago

Has patch: unset
Triage Stage: UnreviewedAccepted

[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 by Malcolm Tredinnick, 15 years ago

Resolution: fixed
Status: newclosed

(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 by Malcolm Tredinnick, 15 years ago

(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 by Malcolm Tredinnick, 15 years ago

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.

Note: See TracTickets for help on using tickets.
Back to Top