Re: all files are executable in vfat

Re: all files are executable in vfat

[Alexander Viro]

On Tue, 25 Sep 2001, Nerijus Baliunas wrote:

> On Tue, 25 Sep 2001 12:09:30 -0400 (EDT) Alexander Viro <viro@math.psu.edu> wrote:
> 
> AV> > All files are executable in vfat (kernel 2.4.10), although I have
> AV> > /dev/hda1  /mnt/c   vfat   defaults,user,noexec,umask=0,quiet 0 0
> AV> > in /etc/fstab. They were not in 2.4.7.
> AV> 
> AV> Really? Try to execute a binary from there.  cp /bin/ls /mnt/c && /mnt/c/ls
> 
> bash: /mnt/c/ls: Permission denied. But:
> $ ls -l ls
> -rwxrwxrwx    1 nerijus  nerijus     45724 Rgs 25 18:12 ls

So use the right option for that - umask=111 and there you go.

noexec doesn't (and shouldn't) do anything about mode.  Yes, VFAT (along
with explicit mechanism for doing what you want to do) used to have a
bug in noexec handling.  And that's a bug - plain and simple.  Try it
on any other UNIX _or_ other filesystem on Linux.

-o noexec means "execve() fails regardless of file permissions".  If you
want "give all regular files rw-rw-rw-" - VFAT has option for that:
umask.

Re: all files are executable in vfat

[Nerijus Baliunas]

On Tue, 25 Sep 2001 12:47:46 -0400 (EDT) Alexander Viro <viro@math.psu.edu> wrote:

AV> > $ ls -l ls
AV> > -rwxrwxrwx    1 nerijus  nerijus     45724 Rgs 25 18:12 ls
AV> 
AV> So use the right option for that - umask=111 and there you go.

Actually I just few minutes ago thought about umask - yes, it helps,
thank you. But now I cannot enter any directory as regular user.

AV> noexec doesn't (and shouldn't) do anything about mode.  Yes, VFAT (along
AV> with explicit mechanism for doing what you want to do) used to have a
AV> bug in noexec handling.  And that's a bug - plain and simple.  Try it
AV> on any other UNIX _or_ other filesystem on Linux.

Because this bug was fixed I thought something broke instead...

AV> -o noexec means "execve() fails regardless of file permissions".  If you
AV> want "give all regular files rw-rw-rw-" - VFAT has option for that:
AV> umask.

Regards,
Nerijus

Re: all files are executable in vfat

[Padraig Brady]

Nerijus Baliunas wrote:

>On Tue, 25 Sep 2001 12:47:46 -0400 (EDT) Alexander Viro <viro@math.psu.edu> wrote:
>
>AV> > $ ls -l ls
>AV> > -rwxrwxrwx    1 nerijus  nerijus     45724 Rgs 25 18:12 ls
>AV> 
>AV> So use the right option for that - umask=111 and there you go.
>
>Actually I just few minutes ago thought about umask - yes, it helps,
>thank you. But now I cannot enter any directory as regular user.
>
I too used noexec to get around this problem. Is there anyway to get umask
to ignore directories? I.E. (v)fat should always leave directories 
executable
in my opinion?

Padraig.

Re: all files are executable in vfat

[William Scott Lockwood III]

dmask?

----- Original Message -----
> I too used noexec to get around this problem. Is there anyway to get umask
> to ignore directories? I.E. (v)fat should always leave directories
executable
> in my opinion?

Re: all files are executable in vfat

[Nerijus Baliunas]

On Tue, 25 Sep 2001 12:19:09 -0500 William Scott Lockwood III <thatlinuxguy@hotmail.com> wrote:

WSLI> dmask?
WSLI> 
WSLI> ----- Original Message -----
WSLI> > I too used noexec to get around this problem. Is there anyway to get umask
WSLI> > to ignore directories? I.E. (v)fat should always leave directories
WSLI> executable
WSLI> > in my opinion?

There is no such option in man and using it did not help.


Regards,
Nerijus

Re: all files are executable in vfat

[William Scott Lockwood III]

I'm sorry, I should have been more specific - should we have a dmask option?
So we could give the sysadmin/user the choice...

----- Original Message -----
From: "Nerijus Baliunas" <nerijus@users.sourceforge.net>
To: "William Scott Lockwood III" <thatlinuxguy@hotmail.com>;
<linux-kernel@vger.kernel.org>; "Alexander Viro" <viro@math.psu.edu>
Sent: Tuesday, September 25, 2001 12:25 PM
Subject: Re: all files are executable in vfat


> On Tue, 25 Sep 2001 12:19:09 -0500 William Scott Lockwood III
<thatlinuxguy@hotmail.com> wrote:
>
> WSLI> dmask?
> WSLI>
> WSLI> ----- Original Message -----
> WSLI> > I too used noexec to get around this problem. Is there anyway to
get umask
> WSLI> > to ignore directories? I.E. (v)fat should always leave directories
> WSLI> executable
> WSLI> > in my opinion?
>
> There is no such option in man and using it did not help.
>
>
> Regards,
> Nerijus
>
> -
> 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/
>

Re: all files are executable in vfat

[Alexander Viro]

On Tue, 25 Sep 2001, William Scott Lockwood III wrote:

> dmask?

Umm... That makes sense.

Re: all files are executable in vfat

[Padraig Brady]

Alexander Viro wrote:

>On Tue, 25 Sep 2001, William Scott Lockwood III wrote:
>
>>dmask?
>>
>Umm... That makes sense.
>

Would make things more complicated though?
Maybe by default (v)fat permissions should be
a+x  on directories and a-x on files. But then
you can't execute any files on (v)fat partitions,
which is equivalent to the noexec option, so I'm
guessing the noexec option was previously overloaded to
do a-x on files so this would be explicit? Maybe
is would be better to put back the old logic? :-)

Padraig.

Re: all files are executable in vfat

[Christian Bornträger]

I also faced this  litte problem.

> Maybe by default (v)fat permissions should be
> a+x  on directories and a-x on files. But then

I could live with this solution.

I could also live with a dmask option. But then it would be great to have 
this option with every file system not only vfat.

> do a-x on files so this would be explicit? Maybe
> is would be better to put back the old logic? :-)

This i my preferred solution. I cannot image a situation where it is useful, 
to have a execution flag on all files, if the file system has a noexec flag.
But I see a lot of problems, like the Midnight Commander Logic.
On the other side, it is quite sensible to remove the execution flags from a 
file if you cannot execute them. 

greetings

Christian Bornträger

Re: all files are executable in vfat

[Oliver Xymoron]

On Tue, 25 Sep 2001, Alexander Viro wrote:

> On Tue, 25 Sep 2001, William Scott Lockwood III wrote:
>
> > dmask?
>
> Umm... That makes sense.

Don't know if you already did this with umask, but {umask dmask uid gid}
probably make sense as per-mountpoint options rather than VFAT-specific
ones.

--
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.."

Re: all files are executable in vfat

[Alexander Viro]

On Tue, 25 Sep 2001, Oliver Xymoron wrote:

> On Tue, 25 Sep 2001, Alexander Viro wrote:
> 
> > On Tue, 25 Sep 2001, William Scott Lockwood III wrote:
> >
> > > dmask?
> >
> > Umm... That makes sense.
> 
> Don't know if you already did this with umask, but {umask dmask uid gid}
> probably make sense as per-mountpoint options rather than VFAT-specific
> ones.

OK, let me put it that way: we need to turn stat() into method call
rather than blind access to inode fields.  Then all these problems
will be very easy to deal with.  Variants of such patch exist and
there is no reasons preventing them that stuff in 2.4 (i.e. no
changes are required in filesystems), but it still needs more local
testing.

Re: all files are executable in vfat

[Oliver Xymoron]

On Tue, 25 Sep 2001, Alexander Viro wrote:

> On Tue, 25 Sep 2001, Oliver Xymoron wrote:
>
> > Don't know if you already did this with umask, but {umask dmask uid gid}
> > probably make sense as per-mountpoint options rather than VFAT-specific
> > ones.
>
> OK, let me put it that way: we need to turn stat() into method call
> rather than blind access to inode fields.  Then all these problems
> will be very easy to deal with.  Variants of such patch exist and
> there is no reasons preventing them that stuff in 2.4 (i.e. no
> changes are required in filesystems), but it still needs more local
> testing.

Mmm.. all of the above are orthogonal options and yet still part of
stat(), so it's not obvious to me how abstracting stat helps here. It
seems you'd need something like stackable filters over a generic (or
fs-specific) stat().

--
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.."

Re: all files are executable in vfat

[Trond Myklebust]

>>>>> " " == Alexander Viro <viro@math.psu.edu> writes:

     > OK, let me put it that way: we need to turn stat() into method
     > call rather than blind access to inode fields.  Then all these
     > problems will be very easy to deal with.

Yes *please*! Finally we could introduce proper support for 64-bit
inode numbers too!

Cheers,
  Trond

Re: all files are executable in vfat

[Alexander Viro]

On 25 Sep 2001, Trond Myklebust wrote:

> >>>>> " " == Alexander Viro <viro@math.psu.edu> writes:
> 
>      > OK, let me put it that way: we need to turn stat() into method
>      > call rather than blind access to inode fields.  Then all these
>      > problems will be very easy to deal with.
> 
> Yes *please*! Finally we could introduce proper support for 64-bit
> inode numbers too!

Right.  As soon as userland is audited for places where it uses int
for storing inode numbers - just a couple of months after MS fixes
all security holes in their software.  By then we'll need 128bit time_t,
though...

Re: all files are executable in vfat

[Trond Myklebust]

>>>>> " " == Alexander Viro <viro@math.psu.edu> writes:

     > On 25 Sep 2001, Trond Myklebust wrote:

    >> Yes *please*! Finally we could introduce proper support for
    >> 64-bit inode numbers too!

     > Right.  As soon as userland is audited for places where it uses
     > int for storing inode numbers - just a couple of months after
     > MS fixes all security holes in their software.  By then we'll
     > need 128bit time_t, though...

Anybody using the fstat64() interface has of course already done this,
and MS are known to be releasing the highly secure Windoze-XP any day
now...

I think I could find a use for the larger time_t too...

Cheers,
  Trond

Re: all files are executable in vfat

[Chris Wright]

* Alexander Viro (viro@math.psu.edu) wrote:
> 
> 
> OK, let me put it that way: we need to turn stat() into method call
> rather than blind access to inode fields.

this would be very useful for lsm.

thanks,
-chris

Re: all files are executable in vfat

[Ignacio Vazquez-Abrams]

On Tue, 25 Sep 2001, Oliver Xymoron wrote:

> On Tue, 25 Sep 2001, Alexander Viro wrote:
>
> > On Tue, 25 Sep 2001, William Scott Lockwood III wrote:
> >
> > > dmask?
> >
> > Umm... That makes sense.
>
> Don't know if you already did this with umask, but {umask dmask uid gid}
> probably make sense as per-mountpoint options rather than VFAT-specific
> ones.

Not for filesystems that store permission info, e.g., ext2, ISO9660+RockRidge,
etc.

-- 
Ignacio Vazquez-Abrams  <ignacio@openservices.net>

Re: all files are executable in vfat

[Florian Weimer]

Ignacio Vazquez-Abrams <ignacio@openservices.net> writes:

> > Don't know if you already did this with umask, but {umask dmask uid gid}
> > probably make sense as per-mountpoint options rather than VFAT-specific
> > ones.
> 
> Not for filesystems that store permission info, e.g., ext2,
> ISO9660+RockRidge, etc.

Sometimes I wish there was a uid/gid option for ext2, too.  (Doing
forensic analysis as root is a bit risky. ;-)

-- 
Florian Weimer 	                  Florian.Weimer@RUS.Uni-Stuttgart.DE
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898

Re: all files are executable in vfat

[Alan Cox]

> > Not for filesystems that store permission info, e.g., ext2,
> > ISO9660+RockRidge, etc.
> 
> Sometimes I wish there was a uid/gid option for ext2, too.  (Doing
> forensic analysis as root is a bit risky. ;-)

Usermode Linux can mount your ext2fs block device in the virtual linux,
and with copy on write of changes to a different file.

Alan

Re: all files are executable in vfat

[Florian Weimer]

Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

> > > Not for filesystems that store permission info, e.g., ext2,
> > > ISO9660+RockRidge, etc.
> > 
> > Sometimes I wish there was a uid/gid option for ext2, too.  (Doing
> > forensic analysis as root is a bit risky. ;-)
> 
> Usermode Linux can mount your ext2fs block device in the virtual linux,
> and with copy on write of changes to a different file.

Usermode Linux is indeed an option, thanks for the suggestions.

BTW, which of the journaling file systems support true read-only
mounts (without replaying the journal and thus writing to disk)?

-- 
Florian Weimer 	                  Florian.Weimer@RUS.Uni-Stuttgart.DE
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898

Re: all files are executable in vfat

[Alan Cox]

> Usermode Linux is indeed an option, thanks for the suggestions.
> 
> BTW, which of the journaling file systems support true read-only
> mounts (without replaying the journal and thus writing to disk)?

None of them, but the UML trick works - maybe we need a generic COW loopback
driver one day

Re: all files are executable in vfat

[Florian Weimer]

Alexander Viro <viro@math.psu.edu> writes:

> On Tue, 25 Sep 2001, William Scott Lockwood III wrote:
> 
> > dmask?
> 
> Umm... That makes sense.

I wrote a small patch for that over a year ago, but it wasn't
integrated because it didn't seem necessary because of the noexec
option, and we didn't know about about the mc problem back then.  The
patch was for 2.2.13.  It featured a critical defect, though.

If there's need for it, I can make a version for 2.4.10.

-- 
Florian Weimer 	                  Florian.Weimer@RUS.Uni-Stuttgart.DE
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898

Re: all files are executable in vfat

[Padraig Brady]

Florian Weimer wrote:

>Alexander Viro <viro@math.psu.edu> writes:
>
>>On Tue, 25 Sep 2001, William Scott Lockwood III wrote:
>>
>>>dmask?
>>>
>>Umm... That makes sense.
>>
>
>I wrote a small patch for that over a year ago, but it wasn't
>integrated because it didn't seem necessary because of the noexec
>option, and we didn't know about about the mc problem back then.
>
It's not just mc. ls coloring, shell tab completion, ...

Padraig.

Re: all files are executable in vfat

[Petr Titera]

Mount with showexec option helps a lot (at least on recent -ac series). With
this option only files executable in Windows environment are marked as
executable.

Petr

all files are executable in vfat

[Nerijus Baliunas]

Hello,

All files are executable in vfat (kernel 2.4.10), although I have
/dev/hda1  /mnt/c   vfat   defaults,user,noexec,umask=0,quiet 0 0
in /etc/fstab. They were not in 2.4.7.

Regards,
Nerijus

Re: all files are executable in vfat

[Alexander Viro]

On Tue, 25 Sep 2001, Nerijus Baliunas wrote:

> Hello,
> 
> All files are executable in vfat (kernel 2.4.10), although I have
> /dev/hda1  /mnt/c   vfat   defaults,user,noexec,umask=0,quiet 0 0
> in /etc/fstab. They were not in 2.4.7.

Really? Try to execute a binary from there.  cp /bin/ls /mnt/c && /mnt/c/ls

Re: all files are executable in vfat

[Nerijus Baliunas]

On Tue, 25 Sep 2001 12:09:30 -0400 (EDT) Alexander Viro <viro@math.psu.edu> wrote:

AV> > All files are executable in vfat (kernel 2.4.10), although I have
AV> > /dev/hda1  /mnt/c   vfat   defaults,user,noexec,umask=0,quiet 0 0
AV> > in /etc/fstab. They were not in 2.4.7.
AV> 
AV> Really? Try to execute a binary from there.  cp /bin/ls /mnt/c && /mnt/c/ls

bash: /mnt/c/ls: Permission denied. But:
$ ls -l ls
-rwxrwxrwx    1 nerijus  nerijus     45724 Rgs 25 18:12 ls

The problem is, mc sees such files as executables and I cannot view
archives by pressing enter on them, instead mc tries to execute them.
Was this change intentional?

Regards,
Nerijus