From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: Date: Thu, 29 Jan 2015 15:41:44 +0100 Message-ID: From: Giacomo Tesio To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=001a11c3da2ea3983c050dcb7cf0 Subject: Re: [9fans] A few questions about 9p Topicbox-Message-UUID: 3de1c7d2-ead9-11e9-9d60-3106f5b1d025 --001a11c3da2ea3983c050dcb7cf0 Content-Type: text/plain; charset=UTF-8 Il 29/Gen/2015 11:12 "Charles Forsyth" ha scritto: > > > On 29 January 2015 at 09:04, Giacomo Tesio 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 --001a11c3da2ea3983c050dcb7cf0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


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.
>
> =C2=A0 =C2=A0 see intro(5) or intro(9P) depending on system. They iden= tify a file on a server; they are a value provided by the server to the cli= ent,
> =C2=A0 =C2=A0 so they only appear in replies.=C2=A0

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

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

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

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

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

Actually if we separate storage and execution, that's pr= obably inevitable.

>>
>> When I should clunk the afid?
>
> =C2=A0 =C2=A0 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 anot= her user.

Thanks again for your help!

Giacomo

--001a11c3da2ea3983c050dcb7cf0--