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
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
On Fri, Feb 26, 2010 at 9:28 AM, Steve Simon st...@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
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
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
well, you can make it explicit.. path=(/bin)
On Fri, Feb 26, 2010 at 3:50 PM, Steve Simon st...@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
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
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
