summaryrefslogtreecommitdiff
path: root/service_solahart_jakarta_selatan__082122541663/exec.mdwn
blob: 05deaa7ad2eb024619e85880cf07e2cc3141792d (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
[[!meta copyright="Copyright © 2010, 2013 Free Software Foundation, Inc."]]

[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with no Invariant
Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
is included in the section entitled [[GNU Free Documentation
License|/fdl]]."]]"""]]

[[!tag open_issue_hurd]]

[[!toc]]


# IRC, unknown channel, unknown date.

    <youpi> oh my, disabling gzip/bzip2 support makes apt preconfigure hang
    <youpi> support in exec* I meant

    <youpi> now a funny bug: if I disable gzip/bzip2 support from exec
    <youpi> trying to run a zero-byte file hangs

Justus: This doesn't seem to be an issue anymore (2013-09-08):

    % touch empty
    % chmod +x empty
    % ./empty
    zsh: exec format error: ./empty
    % bash
    $ ./empty
    $ 

Also I've never encountered a problem with apt.


## IRC, freenode, #hurd, 2013-08-01

    <teythoon> uh, all the non trivial exec server code has #ifdef'd BFD code
      all over it and it looks like that isn't even used anymore
    <teythoon> that's too bad actually, I figured out how to get the values
      from BFD, not so for the other elf parser that is used instead


## IRC, freenode, #hurd, 2013-08-05

    <teythoon> btw, there is a Debian bug concerning zipped executables. now
      I'm not sure if I understood the problem, but gziped and bzip2ed
      executables work for me
    <teythoon> (not that I'm a big fan of that particular feature)
    <youpi> iirc these somehow got fixed yes
    <youpi> something like a previous out of bound access
    <teythoon> the exec server contains lot's of code that is unused and
      probably bit rot (#ifdef BFD) or otherwise ignored (#if 0)
    <youpi> yes :/
    <teythoon> and there's gunzipping and bunzip2ing, which we probably don't
      want anyway
    <pinotree> why not?
    <teythoon> we should strip all that from exec and start adding features
    <teythoon> pinotree: b/c it's slow and the gain is questionable
    <teythoon> it breaks mmapping the code in
    <teythoon> exec/exec.c is huge (~2300 lines) and complex and it is an
      essential server
    <teythoon> and I wonder if the unzipping is done securely, e. g. if it's
      not possible to crash exec with an maliciously compressed executable


## IRC, freenode, #hurd, 2013-09-12

    <rekado> The zip code in hurd/exec/ looks really complicated; does it
      really just unpack zipped files in memory (which could be replaced by
      library calls) or is there something else going on?
    <braunr> rekado:
      http://lists.gnu.org/archive/html/bug-hurd/2013-08/msg00049.html
    <rekado> braunr: interesting. Thanks.
    <rekado> Does this mean that the "small hack entry" on the contributing
      page to use libz and libbz2 in exec is no longer valid?
    <braunr> probably

---

May want to have a look at using BFD / libiberty/simpleobject.

Justus: The BFD code has been removed from the exec server.