[9fans] A few questions about 9p

[9fans] A few questions about 9p

[ibrahim via 9fans]

[-- Attachment #1: Type: text/plain, Size: 1430 bytes --]

I have read the manuals and also searched for this question here without finding an answer (perhaps I missed it) :

1) question about flush :

Lets say there was a pending message with tag=1234 and the client of my server sent a flush message with a tag=1450. During the travel of the flush the server sent a response to the message tagged 1234 cause it finished. 

The manual states that the client has to forget about the flush message as if never sent. Does that mean that message tagged with 1450 which is now ignored by the server won't be replied (no error reply and no success reply cause if the server would reply with rflush the client would take this as if the flush succeeded due to the manual page).

Can a client reuse a tag from an unanswered flush message immediatly (in the example tag 1450) 

2) tversion

A client sends tversion while in the middle of a running session.  Is it right to abort/ignore/close/flush all possibly pending messages from the prior session ? 

The next question is regarding msize[4] in tversion. How should a server respond when msize suggested from the client is to small like msize-IOHDRSIZE< one min_stat_size ?


Thanks in advance ;)

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T04e11fe14739da68-M9512c6004c50d17a43226b7f
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 2209 bytes --]

Re: [9fans] A few questions about 9p

[ron minnich]

[-- Attachment #1: Type: text/plain, Size: 3741 bytes --]

Tflush is harder than it looks, given that it is part of a giant race
condition. Will you get the R for the message you are flushing right after
you send Tflush? What happens at the server? It's fun.

Perhaps one of the biggest uses of 9p, globally, was google's gvisor, which
runs an unimaginably large (to me anyway :-) amount of compute in Google
Cloud. gvisor: https://gvisor.dev/docs/,  Comparison here:
https://www.scitepress.org/Papers/2021/104405/104405.pdf

I suspect more bytes moved through 9p on gvisor in a day than moved on all
other platforms since 2000. All I can say is, it's a lot.

gvisor used to use 9p (my fault :-) and, although we started with Andrey
and Lucho's go9p, at some point it was replaced by Chris Koch's
implementation. It's quite good.

You can see how Chris handled Tflush here:
https://github.com/hugelgupf/p9/blob/main/p9/handlers.go#L104

I'd argue that this may be the most real-world-tested Tflush handler you'll
see. I have seen Tflush handlers that just return, having done nothing, and
it's possible that in many cases, that's good enough. But Chris's code is
VERY heavily tested with real workloads.

I also know, as I saw it many times, that the Plan 9 kernel Tflush could at
times get extremely confused. When we ported it to Akaros, we even saw
cases where Tflush would run out of control and exhaust the XID space,
sending flush after flush as fast as it could create them.

Finally, due to some issues with 9p that could not be fixed, the gvisor
engineers created a new protocol, LISA,
https://github.com/google/gvisor/tree/master/pkg/lisafs, worth reading.

HTH

ron
p.s. FYI, when we first started gvisor, we had it in mind that it could
support Plan 9 binaries, and planned accordingly, but that was never tested.

On Mon, Oct 31, 2022 at 4:15 PM ibrahim via 9fans <9fans@9fans.net> wrote:

> I have read the manuals and also searched for this question here without
> finding an answer (perhaps I missed it) :
>
> 1) question about flush :
>
> Lets say there was a pending message with tag=1234 and the client of my
> server sent a flush message with a tag=1450. During the travel of the flush
> the server sent a response to the message tagged 1234 cause it finished.
>
> The manual states that the client has to forget about the flush message as
> if never sent. Does that mean that message tagged with 1450 which is now
> ignored by the server won't be replied (no error reply and no success reply
> cause if the server would reply with rflush the client would take this as
> if the flush succeeded due to the manual page).
>
> Can a client reuse a tag from an unanswered flush message immediatly (in
> the example tag 1450)
>
> 2) tversion
>
> A client sends tversion while in the middle of a running session.  Is it
> right to abort/ignore/close/flush all possibly pending messages from the
> prior session ?
>
> The next question is regarding msize[4] in tversion. How should a server
> respond when msize suggested from the client is to small like
> msize-IOHDRSIZE< one min_stat_size ?
>
>
> Thanks in advance ;)
>
> *9fans <https://9fans.topicbox.com/latest>* / 9fans / see discussions
> <https://9fans.topicbox.com/groups/9fans> + participants
> <https://9fans.topicbox.com/groups/9fans/members> + delivery options
> <https://9fans.topicbox.com/groups/9fans/subscription> Permalink
> <https://9fans.topicbox.com/groups/9fans/T04e11fe14739da68-M9512c6004c50d17a43226b7f>
>

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T04e11fe14739da68-M2d06525b5c16d6549e9beed9
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 4900 bytes --]

Re: [9fans] A few questions about 9p

[ibrahim via 9fans]

[-- Attachment #1: Type: text/plain, Size: 2991 bytes --]

Thanks for your reply Ron. 

At least now I know that Tflush and Tversion in the middle of a running session can really be beasts and this wasn't only my imagination. 

I'm writing three filesystems for my applications needs. For the first the whole tflush, tversion (which is far more dangerous than tflush for a backend server) isn't important because this is a read-only bootfilesystem which replaces the boot infrastructure (9fat, nvram, kfs/fossil/paqfs/...) with a single partition (without the need to search for plan9.ini, boot, the kernel aso).

The second filesystem is my fileserver/database front-end which resides on a host in the internet. And 9p is poison for this task (as defined in man 5 section). The current 9p protocol resembles in my opinion some kind of a transaction system while lacking the most important message "commit". Tversion starts a transaction (called session in the manual) and Tflush and Tversion are aquivalents to a "rollback" while there is no way to "commit" changes to the server. If the client loses his connection a real world backend would have to rollback all changes. Also Tflush, Tversion would make it necessary to store all changes temporarily while there the only message that represents a semi-commit would be Tclunk. 

The fileservers used on plan9 aren't affected by the lack of a session commit cause kfs as well as fossil are journaling filesystems (at least operatable in this way) but 9p enpowers the client while endangering the server.

I rewrote fcall, lib9p to understand the 9p protocol and decided to write a front-end for my hosted fileserver(database+filesystem) based on a tcp protocol. While a plan9 client establishes a connection with sending Tversion I send a "begin" to the main server. After each Tclunk I send "commit" and "begin" and after a Tflush or Tversion I send a "rollback" and a "begin" to the Server for Tflush an immediate Rflush to the client. I'm not happy with this cause Tclunk as the marker for "commit" and "begin" isn't right but thats the way I did it now.

If I would have the choice I would change 9p :

Tversion 
<==> Tversion (handshake for protocol version and messagesize without rollback functionality)
<==> Tbegin (Starting a transaction/session)

Tflush
<==> Trollback (only a renaming to make clear what is meant)

Tcommit
<==> (End the transaction and make the changes permanent)

While at it I would also reduce the amount of information a client can aquire by a tstat or write with a twstat. I would also make ntags 64 bit or at least 32 bit. 

To summarize : I think the lack of a "commit" while starting a session with Tversion rolling it back with Tflush or Tversion has caused me some headache.

Ron, thanks for replying.


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T04e11fe14739da68-M8716c512cdfc3a448b17a9ca
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 4093 bytes --]

Re: [9fans] A few questions about 9p

[ibrahim via 9fans]

[-- Attachment #1: Type: text/plain, Size: 3061 bytes --]

On Saturday, 5 November 2022, at 12:41 AM, ron minnich wrote:
> I'd argue that this may be the most real-world-tested Tflush handler you'll see. I have seen Tflush handlers that just return, having done nothing, and it's possible that in many cases, that's good enough. But Chris's code is VERY heavily tested with real workloads.

I'm not surprised. Interrupting hardware access for a few kB and risking to damage the filesystem wouldn't be wise. 

On Saturday, 5 November 2022, at 12:41 AM, ron minnich wrote:
> I also know, as I saw it many times, that the Plan 9 kernel Tflush could at times get extremely confused. When we ported it to Akaros, we even saw cases where Tflush would run out of control and exhaust the XID space, sending flush after flush as fast as it could create them.
> 

The rule : 

"Should multiple Tflushes be received for a pending request, they must be answered in order. A Rflush for any of the multiple Tflushes implies an answer for all previous ones. Therefore, should a server receive a request and then multiple flushes for that request, it need respond only to the last flush."

and :

"A Tflush can never be responded to by an Rerror message."

should lead to a dead lock in this situation. Lets say the first Tflush arrived and got responded afterwards all the other Tflushes arrive and can't be responded so all ntags used by Tflush messages after the first can't be used by the client cause there are pending unanswered requests by the client. The server can never respond with an Rerror to a Tflush arriving out of order after the first Tflush got processed. 1) All ntags used for Tflush after the first are considered open. 2) A server can't even hint with an error for a Tflush with an inactive oldtag. Rerror with "error : noldtag invalid" would at least make the ntags reusable for the client. If the client code is conforming to the rules in man(5) Tflush messages can burn all possible ntag values (16 bit).


If 9P2000 won't change at least some changes to the effects of Tflush and handling without breaking compatibility would be possible :

1) If a response to one of sent Tflush messages is made all Tflush messages regarding oldtag are responded not only preceeding ones, cause only one Rflush or only one response to the oldtag is allowed by the server.

more important my suggestion :

2) Tflush also leads to a clunk of a fid. This lets the server decide if it will keep the changes or revert them.

Those two changes would build a "mini-transaction" enviroment :

Topen/Tcreate
==> starts a file transaction

Tflush
==> interrupt file operation for fid associated with oldtag, clunk the fid with a rollback

Tclunk
==> commit changes to the file

Tversion
==> rollback all open changes not commited in the previous session.





------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T04e11fe14739da68-Md0bfd4f48352cded476092f3
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 4492 bytes --]

Re: [9fans] A few questions about 9p

[ori]

Quoth ibrahim via 9fans <9fans@9fans.net>:
> On Saturday, 5 November 2022, at 12:41 AM, ron minnich wrote:
> > I'd argue that this may be the most real-world-tested Tflush handler you'll see. I have seen Tflush handlers that just return, having done nothing, and it's possible that in many cases, that's good enough. But Chris's code is VERY heavily tested with real workloads.
> 
> I'm not surprised. Interrupting hardware access for a few kB and risking to damage the filesystem wouldn't be wise. 
> 
> On Saturday, 5 November 2022, at 12:41 AM, ron minnich wrote:
> > I also know, as I saw it many times, that the Plan 9 kernel Tflush could at times get extremely confused. When we ported it to Akaros, we even saw cases where Tflush would run out of control and exhaust the XID space, sending flush after flush as fast as it could create them.
> > 
> 
> The rule : 
> 
> "Should multiple Tflushes be received for a pending request, they must be answered in order. A Rflush for any of the multiple Tflushes implies an answer for all previous ones. Therefore, should a server receive a request and then multiple flushes for that request, it need respond only to the last flush."
> 
> and :
> 
> "A Tflush can never be responded to by an Rerror message."
> 
> should lead to a dead lock in this situation. Lets say the first Tflush arrived and got responded afterwards all the other Tflushes arrive and can't be responded

This situation is impossible -- you can always respond to a Tflush. Repeated tflushes for the same tag may
simply be coalesced into one response.

> so all ntags used by Tflush messages after the first can't be used by the client cause there are pending unanswered requests by the client. The server can never respond with an Rerror to a Tflush arriving out of order after the first Tflush got processed.

Yes, it responds with an Rflush.

> 1) All ntags used for Tflush after the first are considered open. 2) A server can't even hint with an error for a Tflush with an inactive oldtag.

A flush means "I don't care about the response any more". For example, cancelling the next mouse read before
the mouse moves, because the graphical program is exiting.

> Rerror with "error : noldtag invalid" would at least make the ntags reusable for the client. If the client code is conforming to the rules in man(5) Tflush messages can burn all possible ntag values (16 bit).

As can any other message; this is fine, you don't want 65535 outstanding messages anwyays, most of the time.
 
> 
> If 9P2000 won't change at least some changes to the effects of Tflush and handling without breaking compatibility would be possible :
> 
> 1) If a response to one of sent Tflush messages is made all Tflush messages regarding oldtag are responded not only preceeding ones, cause only one Rflush or only one response to the oldtag is allowed by the server.
> 
> more important my suggestion :
> 
> 2) Tflush also leads to a clunk of a fid. This lets the server decide if it will keep the changes or revert them.

Flushes are fired on interrupt, because the result of an in-flight read or write is no longer needed;
Why would you want an alarm firing to close the file you're reading? that makes no sense.
 
> Those two changes would build a "mini-transaction" enviroment :
> 
> Topen/Tcreate
> ==> starts a file transaction
> 
> Tflush
> ==> interrupt file operation for fid associated with oldtag, clunk the fid with a rollback
> 
> Tclunk
> ==> commit changes to the file
> 
> Tversion
> ==> rollback all open changes not commited in the previous session.

how would this work for file systems like kbdfs, /net, etc? your proposal doesn't work for most of the file systems shipped with plan 9.


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T04e11fe14739da68-Mcfef687d4d59cc5bad0576f2
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] A few questions about 9p

[ibrahim via 9fans]

[-- Attachment #1: Type: text/plain, Size: 1877 bytes --]

Thank you for your clarifications Ori. From the perspective of kernel filesystems what you wrote made things clear. But one question remains regarding tflush and user fileservers :

On Saturday, 5 November 2022, at 5:31 AM, ori wrote:
> This situation is impossible -- you can always respond to a Tflush. Repeated tflushes for the same tag may
simply be coalesced into one response.

tflush is also used to interrupt pending requests in user-file-systems. And there such a situation can happen where you can't respond to a Tflush. The server already processed the message for noldtag and sent its reply. Now you can't reply to a tflush with rflush cause that would mean the Tflush was successful and you can't answer with Rerror cause the rule says that Rerror is not allowed as a response to Tflush messages. Am I right regarding this situation or is this a misunderstanding. 


On Saturday, 5 November 2022, at 5:31 AM, ori wrote:
> how would this work for file systems like kbdfs, /net, etc? your proposal doesn't work for most of the file systems shipped with plan 9.

You are right I only looked at the problems from the perspective of the user-fileservers I am developing right now. And so I tried to understand the possible impact of tflush for data-integrity. 

After your response I'll use this strategy in my user-fileservers :

1) Repond to Tflush right away with Rflush 
2) Revert all changes to the file/directory ==> A full rollback
3) Invalidate the fid and reply with Rerror on the next message where this fid is used.
4) Make changes permanent only after a Tclunk for a valid fid. 
5) Document this behavior.


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T04e11fe14739da68-M613a9a70317e111f7128e8d5
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 2757 bytes --]

Re: [9fans] A few questions about 9p

[ori]

Quoth ibrahim via 9fans <9fans@9fans.net>:
> tflush is also used to interrupt pending requests in user-file-systems. And there such a situation can happen where you can't respond to a Tflush. The server already processed the message for noldtag and sent its reply. Now you can't reply to a tflush with rflush cause that would mean the Tflush was successful and you can't answer with Rerror cause the rule says that Rerror is not allowed as a response to Tflush messages. Am I right regarding this situation or is this a misunderstanding. 

You reply with an Rflush.

The Tflush was successful: The Rflush does not indicate that a message was
cancelled, tit indicates that the server is no longer processing the request.


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T04e11fe14739da68-M44e595e13d13c770dca05d94
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] A few questions about 9p

[ibrahim via 9fans]

[-- Attachment #1: Type: text/plain, Size: 3573 bytes --]

Thanks for your answer.

On Saturday, 5 November 2022, at 3:09 PM, ori wrote:
> The Tflush was successful: The Rflush does not indicate that a message was
cancelled, tit indicates that the server is no longer processing the request.

After your answer an read the manual pages a few times again and now I understand what to do :

1) All Tflush messages get a Rflush reply. If more than one Tflush arrives answering the last one means responding to all of them, like the manual states here :

"A Rflush for any of the multiple Tflushes implies an answer for all previous ones. Therefore, should a server receive a request and then multiple flushes for that request, it need respond only to the last flush."

2)Even when oldtag doesn't represent an active message Tflush gets a Rflush response. 

3) The only indicator for the client if his Tflush didn't interrupt (!!!) an active message cycle is (manual page) :

If a response to the flushed request is received before the Rflush, the client must honor the response as if it had not been flushed, since the completed request may signify a state change in the server. For instance, Tcreate may have created a file and Twalk may have allocated a fid. If no response is received before the Rflush, the flushed transaction is considered to have been canceled, and should be treated as though it had never been sent.

interpreted as : 

a) Server replies to oldtag before sending Rflush ==> indicates oldtag wasn't interrupted
b) Server sends Rflush before responding to oldtag ==> indicates oldtag-message was interrupted

4) Its legal that a client sends Tflush messages with an invalid oldtag for which it can expect an Rflush as response never an Rerror (manual) :

The server should answer the flush message immediately. If it recognizes oldtag as the tag of a pending transaction, it should abort any pending response and discard that tag. In either case, it should respond with an Rflush echoing the tag (not oldtag) of the Tflush message. A Tflush can never be responded to by an Rerror message.


Now my interpretation of Tflush and Rflush quite changed :

It seems that Tflush has at least two functions : 

(1) Interrupt a running message, while the probability to interrupt a running message is very small. 
(2) Polling the fileserver and guessing how it is implemented. A server with a simple sequential message processiong won't be able to respond to a Tflush by Rflush before responding to oldtag. A server which only replies to the n-th Tflush would be lagging and uses a message queue.

Consequences for my implementation :

1) Its not an error if Tflush uses an invalid oldtag even using the ntag of Tflush as oldtag would be valid.
2) Every Tflush gets an Rflush directly or indirectly (response to the last in a series is enough)
3) Tflush can be used/abused to measure the fileserver performance. Send a message and flush it to measure the time needed to process it. Send n messages and measure the response time-differences, aso.
4) Tflush is not related with transactions but has to be taken as a rollback if sent for an oldtag that interrupts a running write operation.


Thanks ori for your clear answers i got the right hints to check my understanding. And I had a misunderstanding regarding tflush till now so I needed to ask ;)

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T04e11fe14739da68-Ma697c45ddea03254971a41da
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 4768 bytes --]

[9fans] A few questions about 9p

[Giacomo Tesio]

[-- Attachment #1: Type: text/plain, Size: 805 bytes --]

Hi, I'm coding a small .NET library to connect 9p2000 services and I have a
few questions about things that the manual doesn't explain (or I was not
able to find).

What's the meaning of qids? I see that responses often include them but
request messages do not.

What's the proper message sequence to delete a file? And to delete a non
empty directly?

Is it possible to move a file between different directories atomically?

I can't find details on the file execution permission: looks like a
malicious client could just ignore it on files and execute anything that it
can read (obviously I'm just talking about single files,  not directory).

When I should clunk the afid?

What about encryption? Is it completely delegated to the transport layer?

Thanks for your help!

Giacomo

[-- Attachment #2: Type: text/html, Size: 968 bytes --]

Re: [9fans] A few questions about 9p

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 1710 bytes --]

On 29 January 2015 at 09:04, Giacomo Tesio <giacomo@tesio.it> wrote:

> What's the meaning of qids? I see that responses often include them but
> request messages do not.
>
    see intro(5) or intro(9P) depending on system. They identify a file on
a server; they are a value provided by the server to the client,
    so they only appear in replies.

> What's the proper message sequence to delete a file? And to delete a non
> empty directly?
>
    You point a fid at the file, then remove it:    Twalk* ... Tremove
    A non-empty directory can't be removed.
    Tremove implies Tclunk

>  Is it possible to move a file between different directories atomically?
>
    No.

> I can't find details on the file execution permission: looks like a
> malicious client could just ignore it on files and execute anything that it
> can read (obviously I'm just talking about single files,  not directory).
>
    It's not malicious, just incorrect. Obviously you can't execute a
remote image or script unless you read it.
    The existing servers treat OEXEC as opening for read, with a check of
the X permission.
    A directory, however, can't be opened OEXEC.
    In the script case, the file server will allow the OEXEC open, but
#!interpreter is converted to {interpreter file},
    and then if the file is x-only, the subsequent open for OREAD will
fail. Possibly the interpreters should open OEXEC, but they don't.

> When I should clunk the afid?
>
    When the client closes it.

> What about encryption? Is it completely delegated to the transport layer?
>
     Yes, for encryption of communication.  A file server could encrypt
files or the whole storage structure.

[-- Attachment #2: Type: text/html, Size: 2825 bytes --]

Re: [9fans] A few questions about 9p

[erik quanstrom]

> > What's the proper message sequence to delete a file? And to delete a non
> > empty directly?
> >
>     You point a fid at the file, then remove it:    Twalk* ... Tremove
>     A non-empty directory can't be removed.
>     Tremove implies Tclunk

the current on-disk file servers do follow this rule, but i don't see it
mentioned in remove(5) and at least nupas, if not the original, will
allow a rm of a message directory, with the expected sematics of
removing the message.  aoe(3) allows target directories to be
removed with rm.

if a sentence were added to remove(5), it might be "removing non-empty
directories may be disallowed by the file server."  i'm not sure that clarifies
things, though.

- erik

Re: [9fans] A few questions about 9p

[Giacomo Tesio]

[-- Attachment #1: Type: text/plain, Size: 1814 bytes --]

Il 29/Gen/2015 11:12 "Charles Forsyth" <charles.forsyth@gmail.com> ha
scritto:
>
>
> On 29 January 2015 at 09:04, Giacomo Tesio <giacomo@tesio.it> wrote:
>>
>> What's the meaning of qids? I see that responses often include them but
request messages do not.
>
>     see intro(5) or intro(9P) depending on system. They identify a file
on a server; they are a value provided by the server to the client,
>     so they only appear in replies.

Thanks Charles for your answer.
Actually I can't imagine it's usage in the client.  I mean: clients should
use path to identify files, shouldn't them?

>>
>> What's the proper message sequence to delete a file? And to delete a non
empty directly?
>
>     You point a fid at the file, then remove it:    Twalk* ... Tremove
>     A non-empty directory can't be removed.
>     Tremove implies Tclunk

Ehm... I didn't saw the Tremove message.. sorry.

>>
>> I can't find details on the file execution permission: looks like a
malicious client could just ignore it on files and execute anything that it
can read (obviously I'm just talking about single files,  not directory).
>
>     It's not malicious, just incorrect. Obviously you can't execute a
remote image or script unless you read it.

By malicious I mean that the client could execute a script that it wasn't
allowed to.

Actually if we separate storage and execution, that's probably inevitable.

>>
>> When I should clunk the afid?
>
>     When the client closes it.

Ok but when should the client close it?

Is it still valid to Tattach after the afid has been closed? How many
times? I'm thinking about potential security issues allowing an attacker to
attach a file server just guessing the afid provided by another user.

Thanks again for your help!

Giacomo

[-- Attachment #2: Type: text/html, Size: 2362 bytes --]

Re: [9fans] A few questions about 9p

[erik quanstrom]

> >> I can't find details on the file execution permission: looks like a
> malicious client could just ignore it on files and execute anything that it
> can read (obviously I'm just talking about single files,  not directory).
> >
> >     It's not malicious, just incorrect. Obviously you can't execute a
> remote image or script unless you read it.
>
> By malicious I mean that the client could execute a script that it wasn't
> allowed to.

if you can read the executable you can already copy it somewhere, set the execute
bit, and away you go.  the x bit is purely advisory.  it is not a security mechanism.

- erik

Re: [9fans] A few questions about 9p

[cinap_lenrek]

          size[4] Tattach tag[2] fid[4] afid[4] uname[s] aname[s]
          size[4] Rattach tag[2] qid[13]

you have to provide the afid in the Tattach, so clunking it before
attach makes no sense. you can pass NOFID to Tattach when when the
fileserver doesnt support authentification.

you can also reuse the afid, so keeping it arround after Tattach
works just fine.

if you only want todo a single attach, you can clunk it after the
Tattach.

its all documented and better worded in attach(5).

--
cinap

Re: [9fans] A few questions about 9p

[Giacomo Tesio]

[-- Attachment #1: Type: text/plain, Size: 793 bytes --]

Actually I wasn't able to understand when the afid was supposed to be clunk
reading attach 5.

I was in doubt that the afid had to be the last fid clunked.

Giacomo
Il 29/Gen/2015 15:56 <cinap_lenrek@felloff.net> ha scritto:

>           size[4] Tattach tag[2] fid[4] afid[4] uname[s] aname[s]
>           size[4] Rattach tag[2] qid[13]
>
> you have to provide the afid in the Tattach, so clunking it before
> attach makes no sense. you can pass NOFID to Tattach when when the
> fileserver doesnt support authentification.
>
> you can also reuse the afid, so keeping it arround after Tattach
> works just fine.
>
> if you only want todo a single attach, you can clunk it after the
> Tattach.
>
> its all documented and better worded in attach(5).
>
> --
> cinap
>
>

[-- Attachment #2: Type: text/html, Size: 1117 bytes --]