Repository navigation
The pwd module doesn't distinguish between errors and no user #48511
Description
| BPO | 4261 |
|---|---|
| Nosy | @vstinner, @bitdancer |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None
closed_at = None
created_at = <Date 2008-11-05.08:19:21.716>
labels = ['extension-modules', 'easy', 'type-bug']
title = "The pwd module doesn't distinguish between errors and no user"
updated_at = <Date 2014-03-23.17:59:38.828>
user = 'https://bugs.python.org/astrand'bugs.python.org fields:
activity = <Date 2014-03-23.17:59:38.828>
actor = 'r.david.murray'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Extension Modules']
creation = <Date 2008-11-05.08:19:21.716>
creator = 'astrand'
dependencies = []
files = []
hgrepos = []
issue_num = 4261
keywords = ['easy']
message_count = 11.0
messages = ['75516', '75519', '101505', '101506', '214528', '214557', '214566', '214574', '214584', '214615', '214623']
nosy_count = 4.0
nosy_names = ['astrand', 'vstinner', 'r.david.murray', 'BreamoreBoy']
pr_nums = []
priority = 'normal'
resolution = 'accepted'
stage = 'test needed'
status = 'languishing'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue4261'
versions = ['Python 3.5']
Activity
astrand commentedon Nov 5, 2008
The getpwnam function in the pwd module does not correctly distinguish
between the case when the user does not exist and error
conditions. getpwnam() returns NULL in both cases, the the calling
code needs to check errno to determine if an error occured or not.
This bug is problematic in conjunction with bug
https://bugzilla.redhat.com/show_bug.cgi?id=470003, since it means
that Pythons getpwnam() will sometimes raise KeyError even for valid
users. How to reproduce:
I was restarting the OpenLDAP server between the first successful call
and the traceback one.
vstinner commentedon Nov 5, 2008
You're right. getpwnam() and getpwuid() have to check errno. A
different error should be raised, something like:
RuntimeError("getpwnam(%s) failure: %s" % (name, strerror(errno)))
The grp should also be affected.
vstinner commentedon Mar 22, 2010
This issue is open since 2 years without any patch. It looks like the feature request is not really important, and I consider that we can close it. Reopen the issue (with a patch!) if you consider that this ticket is important.
bitdancer commentedon Mar 22, 2010
Victor, since this is a real,fixable bug but nobody has stepped forward with a patch, I think it is better make its status 'languishing' with the reason 'no one has stepped forward with a patch'. This kind of thing is exactly what we introduced languishing for. And two years is nothing ;)
BreamoreBoy commentedon Mar 23, 2014
I'm assuming that 2.7 and 3.5 would need patches.
vstinner commentedon Mar 23, 2014
According to the manual page, there is no guarantee that missing user and error give a different result. Extracts of the manual page.
"""
Return Value
The getpwnam() and getpwuid() functions return a pointer to a passwd structure, or NULL if the matching entry is not found or an error occurs. If an error occurs, errno is set appropriately. If one wants to check errno after the call, it should be set to zero before the call.
(...)
Errors
0 or ENOENT or ESRCH or EBADF or EPERM or ...
"""
bitdancer commentedon Mar 23, 2014
I read that first paragraph as the controlling one, and that says that errno will be zero if the problem was that the entry could not be found, and non-zero if some other error occurred.
Raising an error would be a backward incompatible change, so it could only be done in 3.5.
vstinner commentedon Mar 23, 2014
The current code doesn't check errno, but if the result is NULL. NULL is
returned if the user doesn't exist, or if an error occurred. But it looks
like errno is not always 0 when the user doesn't exist.
bitdancer commentedon Mar 23, 2014
Can you think of any circumstance in which getpwnam would be able to read the file to look for the user, and yet errno is non-zero?
vstinner commentedon Mar 23, 2014
Getpwnam() can use a lot of various auth method. For example, an external
LDAP server.
bitdancer commentedon Mar 23, 2014
I don't think that changes the picture. If the error code is non-zero, that means that one of the access methods failed, which means getpwnam can't report reliably whether or not that user exists according to the system configuration.
pythongh-48511: Make pwd and grp recognizing that NULL also can mean …
pythongh-48511: Make pwd and grp expose inner errors
pythongh-48511: Make pwd and grp expose inner errors
pythongh-48511: Make pwd and grp expose inner errors
pythongh-48511: Make pwd and grp expose inner errors
pythongh-48511: Make pwd and grp expose inner errors
pythongh-48511: Make pwd and grp expose inner errors