os.mkdir() handles SETGID inconsistently

[lniles]

BPO	539942
Nosy	@loewis, @warsaw, @akuchling

^{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 = <Date 2004-06-05.21:48:24.000>
created_at = <Date 2002-04-05.19:31:08.000>
labels = ['library']
title = 'os.mkdir() handles SETGID inconsistently'
updated_at = <Date 2004-06-05.21:48:24.000>
user = 'https://bugs.python.org/lniles'

bugs.python.org fields:

activity = <Date 2004-06-05.21:48:24.000>
actor = 'akuchling'
assignee = 'none'
closed = True
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2002-04-05.19:31:08.000>
creator = 'lniles'
dependencies = []
files = []
hgrepos = []
issue_num = 539942
keywords = []
message_count = 9.0
messages = ['10180', '10181', '10182', '10183', '10184', '10185', '10186', '10187', '10188']
nosy_count = 6.0
nosy_names = ['loewis', 'barry', 'akuchling', 'jvr', 'dgrassi', 'lniles']
pr_nums = []
priority = 'normal'
resolution = 'wont fix'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue539942'
versions = []

[lniles]

Under FreeBSD 4.4, with the 2.1.2, 2.1.1 or 1.5.2
library, os.mkdir() does NOT set the SETGID or SETUID
bits, regardless of whether they're specified in the
mode argument to os.mkdir(). The bits can be set via
a call to os.chmod(). This behavior appears to be
inherited from FreeBSD's mkdir() os call. On Linux,
the SETGID/SETUID bits are set via os.mkdir()'s mode
argument. (As near as I can tell, POSIX.1 specifies
yet a different behavior.) This is a bug from the
standpoint of Python's os module providing a uniform
interface.

[loewis]

Logged In: YES
user_id=21627

This is not a bug. The posix module exposes functions from
the OS as-is, not trying to unify them. The os module
re-exposes those functions where available. Minor details of
the behaviour of those functions across platforms are
acceptable. For example, on Windows, os.mkdir does not set
any bits. Instead, ACLs are inherited according to the OS
semantics (i.e. it does on NTFS, but doesn't on FAT32).

If you need a function that makes certain additional
guarantees, write a new function.

[dgrassi]

Logged In: YES
user_id=366473

On Mac OS X which is also a BSD derivative the mode argument to mkdir()is completely ignored. This becomes more of an issue when makedirs() is used because a simple chmod (which does work) is not sufficient if multiple directories were created.

[warsaw]

Logged In: YES
user_id=12800

It's also quite inconvenient for cross platform portability
because now you have to either always call os.chmod()
everytime you call os.mkdir(), or replace os.mkdir() with a
function that does that (so all call sites, even in library
modules actually DTRT).

IWBNI Python's default os.mkdir() provided that cross
platform compatibility.

[jvr]

Logged In: YES
user_id=92689

For the record: I cannot reproduce what dgrassi
reports; the mod argument to os.mkdir() works for
me on MacOSX.

[dgrassi]

Logged In: YES
user_id=366473

Indeed MAC OS X mkdir() is correct, it abides by umask.

[loewis]

Logged In: YES
user_id=21627

POSIX specifies

The file permission bits of the new directory shall be
initialized from mode. These file permission bits of
the mode shall be modified by the process' file creation
mask. When bits in mode other than the file permission
bits are set, the meaning of these additional bits is
implementation-defined.

(see
http://www.opengroup.org/onlinepubs/007904975/functions/mkdir.html)

S_ISGID is such an additional bit, so its meaning is
implementation defined. Portability with respect to S_ISGID
cannot be achieved by implicitly invoking chmod afterwards:
S_ISGID might not be supported for directories at all, or
its meaning might vary from system to system.

So I'd rather honor system policies than trying to cheat them.

*If* somebody tries to produce a patch to provide that
feature, I'd require that a) there is an autoconf test for
it, instead of merely checking whether the system is
FreeBSD; b) no additional system call is made on systems
where mkdir already has the desired effect; and c) that this
deviation from the system's mkdir(2) is properly documented.

[warsaw]

Logged In: YES
user_id=12800

Martin, I agree with all your requirements (this shouldn't
be construed as an offer to produce such a patch!)

[akuchling]

Logged In: YES
user_id=11375

No one seems interested in providing a patch, and there's been no
discussion of this bug for over two years, so I'm going to close it.