Processed: tagging 833557

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> tags 833557 + pending
Bug #833557 [hurd] hurd: PF_LOCAL send/recv don't honor MSG_DONTWAIT
Added tag(s) pending.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
833557: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833557
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Re: [PATCH] [hurd] pflocal/socket.c: Support MSG_DONTWAIT in pflocal send/recv

[Samuel Thibault]

Hello,

Christian Seiler, on Fri 05 Aug 2016 21:09:21 +0200, wrote:
> I've attached a patch that fixes this specific issue for me. I
> probably won't have time to look at the other issue I reported
> here, but with that I'd at least be able to have open-isns
> working on Hurd. (And the patch will likely also fix problems
> in other software.)
> 
> It would be great if you could apply that patch in git.

Applied, thanks!

Samuel

Re: [PATCH] [hurd] pflocal/socket.c: Support MSG_DONTWAIT in pflocal send/recv

[Justus Winter]

Richard Braun  writes:

> On Mon, Aug 08, 2016 at 04:54:47PM +0200, Justus Winter wrote:
>> Richard Braun  writes:
>> > Why not start the translator from the remapped environment too ?
>> 
>> No reason, but this has to be implemented.  I started working on a
>> library for writing such chrooting translators, then got side-tracked by
>> the complexity of the dir_lookup operations.  Currently, remap has a
>> very naive lookup function, fakeroot's is better, but still not
>> sufficient.  I made some patches towards unifying and refactoring the
>> logic used in libdiskfs and libnetfs, but these functions are still huge
>> :/
>
> No, i mean, here, in such a specific case, if the parent translator is
> itself running from the remap env, it should used the custom pflocal
> instance, right ?

No, that doesn't help, because binding a unix socket involves setting a
passive translator, and that is still started by the filesystem
"outside" the chrooted environment:

teythoon@hurdbox /tmp % touch 1
teythoon@hurdbox /tmp % remap /servers/socket/1 /tmp/1 -- /bin/bash
bash: cannot make pipe for command substitution: (ipc/mig) bad request message 
ID
teythoon@hurdbox:/tmp$ exit
/bin/settrans: fsys_goaway: (ipc/mig) server died

(eh, also it is tricky to set up, cannot use bash right away)

teythoon@hurdbox /tmp % remap /servers/socket/1 /tmp/1 -- /bin/sh
$ settrans -a 1 /hurd/pflocal
teythoon@hurdbox:/tmp$ python3
Python 3.5.2+ (default, Aug  5 2016, 08:07:14) 
[GCC 6.1.1 20160705] on gnu0
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket
>>> s = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)
>>> s.bind('/tmp/test.sock')
Traceback (most recent call last):
  File "", line 1, in 
OSError: [Errno 1073741873] Cannot assign requested address
>>> 
teythoon@hurdbox:/tmp$ showtrans test.sock
/hurd/ifsock

I firmly believe that the way to proceed is to teach such chrooting
translators to detect that a node has a passive translator record, and
instead of letting the filesystem start it, it must start the translator
on its own.  Not only gives this much stronger isolation, it is also
necessary for correctness.

Justus


signature.asc
Description: PGP signature

Re: [PATCH] [hurd] pflocal/socket.c: Support MSG_DONTWAIT in pflocal send/recv

[Richard Braun]

On Mon, Aug 08, 2016 at 04:54:47PM +0200, Justus Winter wrote:
> Richard Braun  writes:
> > Why not start the translator from the remapped environment too ?
> 
> No reason, but this has to be implemented.  I started working on a
> library for writing such chrooting translators, then got side-tracked by
> the complexity of the dir_lookup operations.  Currently, remap has a
> very naive lookup function, fakeroot's is better, but still not
> sufficient.  I made some patches towards unifying and refactoring the
> logic used in libdiskfs and libnetfs, but these functions are still huge
> :/

No, i mean, here, in such a specific case, if the parent translator is
itself running from the remap env, it should used the custom pflocal
instance, right ?

-- 
Richard Braun

Re: [PATCH] [hurd] pflocal/socket.c: Support MSG_DONTWAIT in pflocal send/recv

[Justus Winter]

Richard Braun  writes:

> On Mon, Aug 08, 2016 at 12:55:24PM +0200, Justus Winter wrote:
>> Right, I can see how this is a problem.  The thing is, remap doesn't
>> quite do the job: 1/ it fails to remap relative paths, 2/ if one sets a
>> translator record on a node, and that translator is then started by the
>> filesystem, it is started "outside" of the remap environment.  I belive
>> 2/ is what happens here.
>
> Why not start the translator from the remapped environment too ?

No reason, but this has to be implemented.  I started working on a
library for writing such chrooting translators, then got side-tracked by
the complexity of the dir_lookup operations.  Currently, remap has a
very naive lookup function, fakeroot's is better, but still not
sufficient.  I made some patches towards unifying and refactoring the
logic used in libdiskfs and libnetfs, but these functions are still huge
:/

Justus


signature.asc
Description: PGP signature

Re: [PATCH] [hurd] pflocal/socket.c: Support MSG_DONTWAIT in pflocal send/recv

[Richard Braun]

On Mon, Aug 08, 2016 at 12:55:24PM +0200, Justus Winter wrote:
> Right, I can see how this is a problem.  The thing is, remap doesn't
> quite do the job: 1/ it fails to remap relative paths, 2/ if one sets a
> translator record on a node, and that translator is then started by the
> filesystem, it is started "outside" of the remap environment.  I belive
> 2/ is what happens here.

Why not start the translator from the remapped environment too ?

-- 
Richard Braun

Re: [PATCH] [hurd] pflocal/socket.c: Support MSG_DONTWAIT in pflocal send/recv

[Justus Winter]

Christian Seiler  writes:

 Use the remap translator instead, which is one of the things the Hurd
 design allows you to do easily.

 See /bin/remap to easily set one.
>>>
>>> remap doesn't work at all here, programs then complain
>>> that they can't assign requested address when doing any
>>> socket operation.
>> 
>> Seems to work fine here:
>> 
>> teythoon@hurdbox ~ % cd /tmp
>> teythoon@hurdbox /tmp % settrans -ac 1 /hurd/pflocal
>> teythoon@hurdbox /tmp % remap /servers/socket/1 /tmp/1 -- /bin/bash -c 'echo 
>> huhu world | wc'
>>   1   2  11
>
> For pipes yes, for named sockets (which is what open-isns
> uses): no.
>
> $ cd /tmp
> $ settrans -ac 1 /hurd/pflocal
> $ remap /servers/socket/1 /tmp/1 -- python3
> Python 3.5.2+ (default, Aug  5 2016, 08:07:14) 
> [GCC 6.1.1 20160705] on gnu0
> Type "help", "copyright", "credits" or "license" for more information.
 import socket
 s = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)
 s.bind('/tmp/test.sock')
> Traceback (most recent call last):
>   File "", line 1, in 
> OSError: [Errno 1073741873] Cannot assign requested address
>
> (Same also from C programs, Python is just easier to test.)
>
> The same python code works if you run it without remap.

Right, I can see how this is a problem.  The thing is, remap doesn't
quite do the job: 1/ it fails to remap relative paths, 2/ if one sets a
translator record on a node, and that translator is then started by the
filesystem, it is started "outside" of the remap environment.  I belive
2/ is what happens here.

fakeroot has the same problem.  For me, lack of robust lightweight
virtualization this is the most pressing shortcoming of the Hurd, and I
did some work to address this.  Aiui remap/fakeroot must prevent the
filesystem from starting the translator and do it themself to make the
translation more correct.

> Anyway, not terribly important to me, rebooting did work fine
> anyway, and I now have a working patch for open-isns that will
> make it work on Hurd once my other patch against pflocal's
> socket.c is merged.

Cool!

Cheers,
Justus


signature.asc
Description: PGP signature

Re: [PATCH] [hurd] pflocal/socket.c: Support MSG_DONTWAIT in pflocal send/recv

[Christian Seiler]

On 08/08/2016 12:18 PM, Justus Winter wrote:
>> [settrans -ck stuff]
> All in all this was just bad advice.

Ok, good to know. :)

>>> Use the remap translator instead, which is one of the things the Hurd
>>> design allows you to do easily.
>>>
>>> See /bin/remap to easily set one.
>>
>> remap doesn't work at all here, programs then complain
>> that they can't assign requested address when doing any
>> socket operation.
> 
> Seems to work fine here:
> 
> teythoon@hurdbox ~ % cd /tmp
> teythoon@hurdbox /tmp % settrans -ac 1 /hurd/pflocal
> teythoon@hurdbox /tmp % remap /servers/socket/1 /tmp/1 -- /bin/bash -c 'echo 
> huhu world | wc'
>   1   2  11

For pipes yes, for named sockets (which is what open-isns
uses): no.

$ cd /tmp
$ settrans -ac 1 /hurd/pflocal
$ remap /servers/socket/1 /tmp/1 -- python3
Python 3.5.2+ (default, Aug  5 2016, 08:07:14) 
[GCC 6.1.1 20160705] on gnu0
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket
>>> s = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)
>>> s.bind('/tmp/test.sock')
Traceback (most recent call last):
  File "", line 1, in 
OSError: [Errno 1073741873] Cannot assign requested address

(Same also from C programs, Python is just easier to test.)

The same python code works if you run it without remap.

Anyway, not terribly important to me, rebooting did work fine
anyway, and I now have a working patch for open-isns that will
make it work on Hurd once my other patch against pflocal's
socket.c is merged.

Thanks,
Christian

Re: [PATCH] [hurd] pflocal/socket.c: Support MSG_DONTWAIT in pflocal send/recv

[Justus Winter]

Christian Seiler  writes:

> (The following is not really important, rebooting does
> work, so it's not a showstopper.)
>
> On 08/07/2016 09:13 PM, Richard Braun wrote:
>> On Sun, Aug 07, 2016 at 08:44:56PM +0300, Esa Peuha wrote:
 PS: Is there any way to sanely restart /hurd/pflocal without
 rebooting?
>>>
>>> Yes, the commands to do that are
>>>
>>> settrans -ck /servers/socket/1
>>> settrans -ck /servers/socket/1 /hurd/pflocal
>
> FYI: that's really weird: the translater appears to be
> replaced on my system (up to date Debian sid), but from
> the response of programs, the old one still appears to
> be used.

Yes, that's what the -k is for, it keeps the old translator running.
Also, without specifying -a, settrans only stores the translator record,
which does not change.  -c creates the node, which already exists.  All
in all this was just bad advice.

>> Use the remap translator instead, which is one of the things the Hurd
>> design allows you to do easily.
>> 
>> See /bin/remap to easily set one.
>
> remap doesn't work at all here, programs then complain
> that they can't assign requested address when doing any
> socket operation.

Seems to work fine here:

teythoon@hurdbox ~ % cd /tmp
teythoon@hurdbox /tmp % settrans -ac 1 /hurd/pflocal
teythoon@hurdbox /tmp % remap /servers/socket/1 /tmp/1 -- /bin/bash -c 'echo 
huhu world | wc'
  1   2  11


Cheers,
Justus


signature.asc
Description: PGP signature

Re: [PATCH] [hurd] pflocal/socket.c: Support MSG_DONTWAIT in pflocal send/recv

[Christian Seiler]

(The following is not really important, rebooting does
work, so it's not a showstopper.)

On 08/07/2016 09:13 PM, Richard Braun wrote:
> On Sun, Aug 07, 2016 at 08:44:56PM +0300, Esa Peuha wrote:
>>> PS: Is there any way to sanely restart /hurd/pflocal without
>>> rebooting?
>>
>> Yes, the commands to do that are
>>
>> settrans -ck /servers/socket/1
>> settrans -ck /servers/socket/1 /hurd/pflocal

FYI: that's really weird: the translater appears to be
replaced on my system (up to date Debian sid), but from
the response of programs, the old one still appears to
be used.

> Use the remap translator instead, which is one of the things the Hurd
> design allows you to do easily.
> 
> See /bin/remap to easily set one.

remap doesn't work at all here, programs then complain
that they can't assign requested address when doing any
socket operation.

Regards,
Christian