This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: The pwd module doesn't distinguish between errors and no user
Type: behavior Stage: test needed
Components: Extension Modules Versions: Python 3.5
process
Status: languishing Resolution: accepted
Dependencies: Superseder:
Assigned To: Nosy List: BreamoreBoy, astrand, r.david.murray, vstinner
Priority: normal Keywords: easy

Created on 2008-11-05 08:19 by astrand, last changed 2022-04-11 14:56 by admin.

Messages (11)
msg75516 - (view) Author: Peter Åstrand (astrand) * (Python committer) Date: 2008-11-05 08:19
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:

$ python
Python 2.4.3 (#1, Jan 14 2008, 18:32:40)
[GCC 4.1.2 20070626 (Red Hat 4.1.2-14)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import pwd
>>> pwd.getpwnam("astrand")
('astrand', '*', 164, 20164, 'Peter Astrand', '/home/astrand', '/bin/bash')
>>>
>>> pwd.getpwnam("astrand")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
KeyError: 'getpwnam(): name not found: astrand'
>>>
>>> pwd.getpwnam("astrand")
('astrand', '*', 164, 20164, 'Peter Astrand', '/home/astrand', '/bin/bash')
>>>

I was restarting the OpenLDAP server between the first successful call
and the traceback one.
msg75519 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2008-11-05 09:00
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.
msg101505 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2010-03-22 13:05
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.
msg101506 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2010-03-22 13:55
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 ;)
msg214528 - (view) Author: Mark Lawrence (BreamoreBoy) * Date: 2014-03-23 00:42
I'm assuming that 2.7 and 3.5 would need patches.
msg214557 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2014-03-23 09:56
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 ...

    The given name or uid was not found. 
"""

errno=0 is not always the case for mising user.
msg214566 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2014-03-23 12:13
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.
msg214574 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2014-03-23 13:15
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.
msg214584 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2014-03-23 14:45
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?
msg214615 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2014-03-23 17:12
Getpwnam() can use a lot of various auth method. For example, an external
LDAP server.
msg214623 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2014-03-23 17:59
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.
History
Date User Action Args
2022-04-11 14:56:40adminsetgithub: 48511
2014-03-23 17:59:38r.david.murraysetmessages: + msg214623
2014-03-23 17:12:59vstinnersetmessages: + msg214615
2014-03-23 14:45:57r.david.murraysetmessages: + msg214584
2014-03-23 13:15:13vstinnersetmessages: + msg214574
2014-03-23 12:13:49r.david.murraysetmessages: + msg214566
versions: - Python 2.7
2014-03-23 09:56:57vstinnersetmessages: + msg214557
2014-03-23 00:42:42BreamoreBoysetnosy: + BreamoreBoy

messages: + msg214528
versions: + Python 3.5, - Python 2.6, Python 3.1, Python 3.2
2010-03-22 13:55:30r.david.murraysetstatus: closed -> languishing


keywords: + easy
stage: test needed
versions: + Python 2.6, Python 3.1, Python 2.7, Python 3.2, - Python 2.4
nosy: + r.david.murray
messages: + msg101506
priority: normal
components: + Extension Modules, - Library (Lib)
resolution: wont fix -> accepted
2010-03-22 13:06:24vstinnersetresolution: fixed -> wont fix
2010-03-22 13:05:29vstinnersetstatus: open -> closed
resolution: fixed
messages: + msg101505
2008-11-05 09:00:20vstinnersetnosy: + vstinner
messages: + msg75519
2008-11-05 08:19:21astrandcreate