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
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
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
Followup to: <[email protected]>
By author: Marko Kreen <[email protected]>
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
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <[email protected]>
On Wed, Oct 10, 2001 at 06:10:15PM -0700, H. Peter Anvin wrote:
> Followup to: <[email protected]>
> By author: Marko Kreen <[email protected]>
> 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
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
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
http://www.kernel.org/pub/linux/kernel/v2.4/linux-2.4.11-dontuse.tar.gz
What the hell is goin on?
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 [email protected]
> 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
[email protected] / 93445641
http://www.nextframe.net
> 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.