[RFC] behaviour of stat() variants (was Re: 2.4.11: mount flag noexec still broken for VFAT partition)

From: Alexander Viro (viro@math.psu.edu)
Date: Wed Oct 10 2001 - 21:07:46 EST

On 10 Oct 2001, H. Peter Anvin wrote:

> flags. Files and directories have syntesized attributes of
> (0777 & ~umask); noexec is supposed to modify that to (0666 & ~umask)
> for files but not directories.
> That has been the Linux behaviour since the 0.x days.

It looks like a horrible kludge, but it can be restored. Actually, that
brings another issue: stat(2) and friends.

We've got a lot of stat(2) versions. 9 in fs/stat.c are only a small part
of that - there is a plenty in arch/*. They were mostly copied from
fs/stat.c and by now bitrot gave a lot of breakage - especially in handling
large UIDs and large files. I have a preliminary patch that cleans that
stuff up and makes very nice tricks possible for filesystems, but it needs
sorting this out - I'm not too happy about guessing the intended behaviour
for dozens of broken stat() versions. Below is the list (from -ac - one
for Linus' tree is a subset) and I would really like to hear comments from
the maintainers.

I've put here only stat() variants - corresponding l- and f- versions should
obviously behave the same way. I've written down the current behaviour
(there may be a couple of places where I've been wrong - it had been a
lot of digging through include/asm-*/{stat,types}.h). What I would like
to see is _intended_ behaviour of these beasts. Notation: UID - 16
is "folds to 16 bit", 32 - "stores 32bit value into apparently 32bit field",
truncated - the rest (32 bits into 16 bit field or blindly truncate to
16 bit and store the result). Size - 64 is "64 bit field", LFS - "stores
into 32bit field if withing limits, -EOVERFLOW otherwise", truncated -
"blindly truncate to 32 bits and store the result".

Some of these are _obviously_ bogus - e.g. on x86-64 _all_ variants of
stat() fold UIDs to 16 bits, on ppc64 all variants available to 64bit
binaries blindly truncate the file sizes to 32 bits, etc.

Folks, please post the intended behaviour for these functions. Preferably
as corrections to the list below...

function UID size

sys_newstat 32 64
sys_newstat 16 LFS
sys_stat64 32 64
cris, i386, m68k, ppc, sh:
sys_stat 16 LFS
sys_newstat 16 LFS
sys_stat64 32 64
sys_newstat 16 LFS
sys_stat64 32 64
sys_stat 32 LFS
sys_newstat 32 LFS
sys_stat64 32 64
irix_xstat 32 LFS
sys_newstat 32 64
sys32_newstat 16 truncated
sys_stat64 32 64
solaris_stat 32 truncated
solaris_stat64 32 64
sys_stat truncated truncated
sys_newstat truncated truncated
sys32_stat 16 truncated
sys32_newstat 16 truncated
sys_stat64 32 64
sys_stat 32 64
sys_newstat 32 64
sys32_newstat 32 truncated
sys_newstat 32 64
sys32_newstat truncated truncated
ia64_oldstat 16 truncated
sys_newstat 16 64
sys32_newstat 16 truncated
sys32_stat64 16 64
sys_newstat 32 64/LFS
hpux_stat64 32 64/LFS
sys_newstat 16 LFS
sys_stat64 32 64
sys_newstat 32 64
sys32_newstat 16 truncated
sys32_stat64 32 64

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

This archive was generated by hypermail 2b29 : Mon Oct 15 2001 - 21:00:36 EST