[9fans] exec permission on plan9

[9fans] exec permission on plan9

[Steve Simon]

Who enforces the exec bit on plan9?

It appears to me (though my code may be buggy) that
the file server is expected to enforce the exec bit
in the file's modes when a file is opened with OEXEC.

I would have expected rc(1) to have checked the mode and
not to have tried to exec() the file if the exec bit in the
file's mode is not set.

Is it another case of "This is Plan9 not Unix" or perhaps
I am mis-remembering that too?

-Steve

Re: [9fans] exec permission on plan9

[erik quanstrom]

> It appears to me (though my code may be buggy) that
> the file server is expected to enforce the exec bit
> in the file's modes when a file is opened with OEXEC.

yes.

> I would have expected rc(1) to have checked the mode and
> not to have tried to exec() the file if the exec bit in the
> file's mode is not set.

rc does check, but the check is not bulletproof:

from plan9.c:/^Executable

	ret = ((statbuf->mode&0111)!=0 && (statbuf->mode&DMDIR)==0);

rc will try to execute a file for which the owner
has execute permission, but you are not the owner.
byron's rc goes to great pains to get this right, but
in plan 9 it's not really possible since there is no
way to get a user's groups.  since this is a property
of the fileserver, and by design you're not supposed
to know those things.  :-)

- erik

Re: [9fans] exec permission on plan9

[Russ Cox]

On Fri, Feb 26, 2010 at 9:28 AM, Steve Simon <steve@quintile.net> wrote:
> Who enforces the exec bit on plan9?
>
> It appears to me (though my code may be buggy) that
> the file server is expected to enforce the exec bit
> in the file's modes when a file is opened with OEXEC.
>
> I would have expected rc(1) to have checked the mode and
> not to have tried to exec() the file if the exec bit in the
> file's mode is not set.
>
> Is it another case of "This is Plan9 not Unix" or perhaps
> I am mis-remembering that too?

I think enforce is the wrong mindset.  (This is Plan 9, not Unix.)
OEXEC and OREAD are just two different ways
to open a file for reading.  As a convenience to exec
more than anything else, most file servers associate
them with different permission bits, but absolutely
nothing stops you from reading an 0111 file or
executing an 0444 file; in both cases, open it with
the right mode, read out a copy, and change the
bits on your own copy.

Russ

Re: [9fans] exec permission on plan9

[Steve Simon]

I should have explained my problem.

I build tools for an embedded system with gcc under windows,
I cd into that directory (using my cifs) client and type ls
and get an "invalid exec format" error; I swear and type /bin/ls
and get what I expect.

I think my cifs client should fail all attempts to open files
with OEXEC as it is unlikely that I will be storing plan9 executables
on windows.

Thanks for the help guys.

-Steve

Re: [9fans] exec permission on plan9

[erik quanstrom]

is there a file named "ls" in the cifs directory?  if not, wouldn't
the bug be that the cifs server is allowing an open of a file
that's not there?

- erik

Re: [9fans] exec permission on plan9

[Steve Simon]

> is there a file named "ls" in the cifs directory?  if not, wouldn't
> the bug be that the cifs server is allowing an open of a file
> that's not there?

There is a file in the directory, its just not a plan9 executable,
its an ARM ELF file.

-Steve

Re: [9fans] exec permission on plan9

[Federico G. Benavento]

well, you can make it explicit.. path=(/bin)

On Fri, Feb 26, 2010 at 3:50 PM, Steve Simon <steve@quintile.net> wrote:
> I should have explained my problem.
>
> I build tools for an embedded system with gcc under windows,
> I cd into that directory (using my cifs) client and type ls
> and get an "invalid exec format" error; I swear and type /bin/ls
> and get what I expect.
>
> I think my cifs client should fail all attempts to open files
> with OEXEC as it is unlikely that I will be storing plan9 executables
> on windows.
>
> Thanks for the help guys.
>
> -Steve
>
>



--
Federico G. Benavento

Re: [9fans] exec permission on plan9

[Lyndon Nerenberg (VE6BBM/VE7TFX)]

> well, you can make it explicit.. path=(/bin)

Which really should be the default, or at least path=(/bin .).

Putting '.' at the front means that wherever you're cd'ed into a
remote directory, every command you run is 9Peeing off to the remote
host looking for a command that's most likely not going to be there.
When your RTTs get into the 100ms+ range, things quickly get very
painful.

Fixing path= in /rc/lib/rcmain will make your life a lot happier if you
work with a lot of remote 9P mounts.

--lyndon