Bug 124037 - os.access erroneously reports writable file not writable in setuid environment
Summary: os.access erroneously reports writable file not writable in setuid environment
Alias: None
Product: Fedora
Classification: Fedora
Component: python   
(Show other bugs)
Version: 2
Hardware: i386 Linux
Target Milestone: ---
Assignee: Mihai Ibanescu
QA Contact: Brock Organ
Depends On:
TreeView+ depends on / blocked
Reported: 2004-05-23 03:19 UTC by Myk Melez
Modified: 2007-11-30 22:10 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-09-30 16:04:21 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Myk Melez 2004-05-23 03:19:55 UTC
Description of problem:

I wrap a Python CGI with a setuid wrapper written in C.  When
executing this program on my Fedora Core 2 workstation,
os.access(<filename>, os.W_OK) returns 0 (i.e. "not accessible") for a
file that *is* writable by the owner of the CGI, i.e. the user to
which the effective UID has been set.  os.geteuid correctly returns
the effective UID of the CGI owner, but os.access apparently looks
elsewhere for that value, although its documentation claims:

access(  	path, mode)
    Use the real uid/gid to test for access to path. Note that most
operations will use the effective uid/gid, therefore this routine can
be used in a suid/sgid environment to test if the invoking user has
the specified access to path.


Note that "man 2 access," which documents the system call os.access
uses, also claims to be using the real uid/gid, but it never claims to
use the effective uid/gid or be usable in a setuid environment (except
for determining whether the invoking user would have access to a file
that the effective user has access to).

This may not be a bug, since os.access only claims to use the
effective UID most of the time, but if not it's at least worthy of
documentation in release notes.  Note that the script I'm writing on
my Fedora workstation gets published to a FreeBSD 4.8-STABLE server
also running Python 2.3.3 on which this problem does not occur.

Version-Release number of selected component (if applicable): Fedora
Core 2, Python 2.3.3

How reproducible: Happens every time.

Comment 1 Mihai Ibanescu 2004-07-29 22:55:18 UTC
will have a look.

Comment 2 Matthew Miller 2005-04-26 15:29:46 UTC
Fedora Core 2 is now maintained by the Fedora Legacy project for
security updates only. If this problem is a security issue, please
reopen and reassign to the Fedora Legacy product. If it is not a
security issue and hasn't been resolved in the current FC3 updates or
in the FC4 test release, reopen and change the version to match.

Note You need to log in before you can comment on or make changes to this bug.