2.4.11: mount flag noexec still broken for VFAT partition

2.4.11: mount flag noexec still broken for VFAT partition

[Andris Pavenis]

Similary as with 2.4.10 mount flag noexec does not work for VFAT
partition. I have following in fstab

/dev/hda1      /c       vfat     noexec,gid=201,umask=002,quiet  1    0
/dev/hda5      /d       vfat     noexec,gid=201,umask=002,quiet  1    0

but I see that all files in corresponding filesystems are still 
exectuable

Andris

Re: 2.4.11: mount flag noexec still broken for VFAT partition

[Andreas Dilger]

On Oct 10, 2001  23:01 +0300, Andris Pavenis wrote:
> Similary as with 2.4.10 mount flag noexec does not work for VFAT
> partition. I have following in fstab
> 
> /dev/hda1      /c       vfat     noexec,gid=201,umask=002,quiet  1    0
> /dev/hda5      /d       vfat     noexec,gid=201,umask=002,quiet  1    0
> 
> but I see that all files in corresponding filesystems are still 
> exectuable

Probably because your uid or gid match the above, so your access permission
is done by checking "user" or "group" and not "other".  Try "umask=113"
instead.

Cheers, Andreas
--
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert

Re: 2.4.11: mount flag noexec still broken for VFAT partition

[Marko Kreen]

On Wed, Oct 10, 2001 at 03:13:33PM -0600, Andreas Dilger wrote:
> On Oct 10, 2001  23:01 +0300, Andris Pavenis wrote:
> > Similary as with 2.4.10 mount flag noexec does not work for VFAT
> > partition. I have following in fstab
> > 
> > /dev/hda1      /c       vfat     noexec,gid=201,umask=002,quiet  1    0
> > /dev/hda5      /d       vfat     noexec,gid=201,umask=002,quiet  1    0
> > 
> > but I see that all files in corresponding filesystems are still 
> > exectuable
> 
> Probably because your uid or gid match the above, so your access permission
> is done by checking "user" or "group" and not "other".  Try "umask=113"
> instead.

Um.  'noexec' does not touch flags, it only disallows exec'ing
on particular mountpoint.  So Andris, have you tried executing
anything on those partitions?

umask also sets directory permissions, so with umask=113 you
cant acces any dirs there...

-- 
marko

Re: 2.4.11: mount flag noexec still broken for VFAT partition

[H. Peter Anvin]

Followup to:  <20011011003609.B18573@l-t.ee>
By author:    Marko Kreen <marko@l-t.ee>
In newsgroup: linux.dev.kernel
> 
> Um.  'noexec' does not touch flags, it only disallows exec'ing
> on particular mountpoint.
> 

It does on FAT filesystems (except UMSDOS), since they don't have real
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.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>

Re: 2.4.11: mount flag noexec still broken for VFAT partition

[Marko Kreen]

On Wed, Oct 10, 2001 at 06:10:15PM -0700, H. Peter Anvin wrote:
> Followup to:  <20011011003609.B18573@l-t.ee>
> By author:    Marko Kreen <marko@l-t.ee>
> In newsgroup: linux.dev.kernel
> > 
> > Um.  'noexec' does not touch flags, it only disallows exec'ing
> > on particular mountpoint.
> > 
> 
> It does on FAT filesystems (except UMSDOS), since they don't have real
> 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.

Eh.  Seems my brain has managed to filter that out thus far.
Probably as "uninteresting" is the only thing I can say :)

What is interesting is that in current vfat I can toggle
+x bit on and off with chmod.  So it seems like VFS does
not consult with fs anymore about bits.  But you know
that already.

Oh well...

-- 
marko

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

[Alexander Viro]

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

alpha:
sys_newstat	32	64
arm:
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
sparc:
sys_newstat	16	LFS
sys_stat64	32	64
mips:
sys_stat	32	LFS
sys_newstat	32	LFS
sys_stat64	32	64
irix_xstat	32	LFS
sparc64:
sys_newstat	32	64
sys32_newstat	16	truncated
sys_stat64	32	64
solaris_stat	32	truncated
solaris_stat64	32	64
ppc64:
sys_stat	truncated truncated
sys_newstat	truncated truncated
sys32_stat	16	truncated
sys32_newstat	16	truncated
sys_stat64	32	64
mips64:
sys_stat	32	64
sys_newstat	32	64
sys32_newstat	32	truncated
ia64:
sys_newstat	32	64
sys32_newstat	truncated truncated
ia64_oldstat	16	truncated
x86_64:
sys_newstat	16	64
sys32_newstat	16	truncated
sys32_stat64	16	64
parisc:
sys_newstat	32	64/LFS
hpux_stat64	32	64/LFS
s390:
sys_newstat	16	LFS
sys_stat64	32	64
s390x:
sys_newstat	32	64
sys32_newstat	16	truncated
sys32_stat64	32	64

Re: 2.4.11: mount flag noexec still broken for VFAT partition

[Andris Pavenis]

On Thu, 11 Oct 2001, Marko Kreen wrote:

> On Wed, Oct 10, 2001 at 03:13:33PM -0600, Andreas Dilger wrote:
> > On Oct 10, 2001  23:01 +0300, Andris Pavenis wrote:
> > > Similary as with 2.4.10 mount flag noexec does not work for VFAT
> > > partition. I have following in fstab
> > > 
> > > /dev/hda1      /c       vfat     noexec,gid=201,umask=002,quiet  1    0
> > > /dev/hda5      /d       vfat     noexec,gid=201,umask=002,quiet  1    0
> > > 
> > > but I see that all files in corresponding filesystems are still 
> > > exectuable
> > 
> > Probably because your uid or gid match the above, so your access permission
> > is done by checking "user" or "group" and not "other".  Try "umask=113"
> > instead.
> 
> Um.  'noexec' does not touch flags, it only disallows exec'ing
> on particular mountpoint.  So Andris, have you tried executing
> anything on those partitions?
> 
> umask also sets directory permissions, so with umask=113 you
> cant acces any dirs there...
> 

Yes I cannot really execute them (or some Linux executable if I copy it
there). I didn't verify it earlier. Anyway I better liked behaviour of 2.2
kernels and also 2.4 kernels up to rather recent time when 
'ls -l' listed files as not executable (the same with mc)

Andris

linux-2.4.11-dontuse Why?

[Sergey S. Kostyliov]

http://www.kernel.org/pub/linux/kernel/v2.4/linux-2.4.11-dontuse.tar.gz

What the hell is goin on?

Re: linux-2.4.11-dontuse Why?

[Morten Helgesen]

Have a look at what Linus posted a couple of minutes ago.

== Morten

On Thu, Oct 11, 2001 at 12:14:40PM +0400, Sergey S. Kostyliov wrote:
> 
> http://www.kernel.org/pub/linux/kernel/v2.4/linux-2.4.11-dontuse.tar.gz
> 
> What the hell is goin on?
> -
> 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/

-- 
mvh
Morten Helgesen 
UNIX System Administrator & C Developer 
Nextframe AS
admin@nextframe.net / 93445641
http://www.nextframe.net

Re: 2.4.11: mount flag noexec still broken for VFAT partition

[Peter Bornemann]

> Yes I cannot really execute them (or some Linux executable if I copy it
> there). I didn't verify it earlier. Anyway I better liked behaviour of 2.2
> kernels and also 2.4 kernels up to rather recent time when
> 'ls -l' listed files as not executable (the same with mc)

Somebody on this list posted a rather clean solution: there is a
"showexec"-flag for MS-filesystems, which shows only files .exe, .com or
.bat extensions as executable. This is a better thing than to play with
umask I think. Umask will give problems with wine and (maybe) dosemu.

Best wishes

Peter B


Microsoft is not the solution, it is the problem.