New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The pwd module doesn't distinguish between errors and no user #48511
Comments
The getpwnam function in the pwd module does not correctly distinguish This bug is problematic in conjunction with bug $ 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 |
You're right. getpwnam() and getpwuid() have to check errno. A The grp should also be affected. |
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. |
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 ;) |
I'm assuming that 2.7 and 3.5 would need patches. |
According to the manual page, there is no guarantee that missing user and error give a different result. Extracts of the manual page. """ 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 ...
""" errno=0 is not always the case for mising user. |
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. |
The current code doesn't check errno, but if the result is NULL. NULL is |
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? |
Getpwnam() can use a lot of various auth method. For example, an external |
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. |
Distinguish between the case when the user/group does not exist and error conditions. If the user does not exit, raise KeyError as now, for errors raise OSError.
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:
bugs.python.org fields:
Linked PRs
The text was updated successfully, but these errors were encountered: