1 |
On 08/26/14 21:21, Rick "Zero_Chaos" Farina wrote: |
2 |
> -----BEGIN PGP SIGNED MESSAGE----- |
3 |
> Hash: SHA1 |
4 |
> |
5 |
> On 08/26/2014 06:23 PM, Anthony G. Basile wrote: |
6 |
>> On 08/26/14 17:00, Alexander Tsoy wrote: |
7 |
>>> On Tue Aug 26 22:27:36 2014 Anthony G. Basile <blueness@g.o> |
8 |
>>> wrote: |
9 |
>>>> Hi everyone, |
10 |
>>>> |
11 |
>>>> I plan to update the pax-utils.eclass because of bug #520198. Can |
12 |
>>>> people please review that bug and the latest suggestion for the eclass. |
13 |
>>>> Since I'm inverting some if and for blocks, a diff isn't as useful as |
14 |
>>>> just looking at the entire class. |
15 |
>>>> |
16 |
>>> What if scanelf will fail? Looks like pax-mark() will not report an |
17 |
>>> error. |
18 |
>> scanelf doesn't return an error code on failing to pax mark. The paxctl |
19 |
>> and paxctl-ng do. eg. |
20 |
> Maybe we should read the pax marks back to verify if it works or not |
21 |
> instead of trusting the return code? We could do it just for scanelf. |
22 |
> |
23 |
> - -Zero |
24 |
|
25 |
scanelf is the last line of defense. If we get there, paxctl and |
26 |
paxctl-ng have failed, so we can't trust them really. Changing the exit |
27 |
code for scanelf could cause other issues, eg in portage where it is |
28 |
used in a few places. As we discussed today during the Hardened |
29 |
meeting, we'll ewarn if we get here. |
30 |
|
31 |
>> blueness@yellow /tmp $ rm -f abc |
32 |
>> blueness@yellow /tmp $ touch abc |
33 |
>> blueness@yellow /tmp $ scanelf -Xx abc >/dev/null ; echo $? |
34 |
>> 0 |
35 |
>> |
36 |
>> If you want a more sophisticated example, remove the PT_PAX_FLAGS |
37 |
>> program header from an elf and you get the same results. I don't think |
38 |
>> its wise to change the behavior of scanelf because its used in portage |
39 |
>> eg in constructing NEEDED.ELF.2. So its not clear what the unintended |
40 |
>> consequences would be if we did report an error here. vapier would be |
41 |
>> able to better address that. I just wrote the eclass following the |
42 |
>> current behaviour. |
43 |
>> |
44 |
>>> And there are unused variables in pax-mark(): pt_fail* and xt_fail*. |
45 |
>>> |
46 |
>> Thanks for catching the cruft. |
47 |
>> |
48 |
>> |
49 |
> -----BEGIN PGP SIGNATURE----- |
50 |
> Version: GnuPG v2 |
51 |
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ |
52 |
> |
53 |
> iQIcBAEBAgAGBQJT/TKeAAoJEKXdFCfdEflKYB0QAKB/qpHKdqBkoG2lB9dH+1RG |
54 |
> qIEyqHdf/SFDem31n1WO5On14enSn+cxafltTvg0emL34emg8v1Y0qD3s0CqXt4K |
55 |
> juX3X8tCnT0CMME/Q4+mgs7aF2+/SLKliUQQ0H842xSSgBGS6uXy6hLa9p0wLOGL |
56 |
> l9tzSjHGDBuTFdqZEqWiPVKOWw5loKZto0w8z6xHyFicEvNGGIaUZcpvvHs8dM26 |
57 |
> aDICXrWqbU6dP8rU2AA8CSapEoFjuOQHQWPCzaIGlABSb9X9N/dbeS27bVQdiQm4 |
58 |
> MBOEJHr9EPYwRRFJ8/XagCRDe3gUgh9p+WROnHZVblMkKRbUJvLqyYSLT220hdRi |
59 |
> lwFJb8kiXfP446jk821wu2xbf0DYCuqOJFTUL/2lcXUO7atIQJqOlOYlpfL7IGSn |
60 |
> RYKxDaJSoaxuGkMsqgKcp9gZ8AD/VT6uD1r6iTTkmCAnVQj4UB02XDc+r6+coyUc |
61 |
> PTjyDiOeQHUhjvoWuJBxAT+TWNZRWXdIkIS1CzGHuCoovGyba+k9JfsOmmFX1HNR |
62 |
> vFzSnOZ+AwIZSk0Mwbm7yeigrXlnPax3D7cRAACif9+fgkXolYr7NYZWgUuEYmDg |
63 |
> 0BAjAsnK1Hr+UhQ6PmcLy8DH5svV9WaQcTWEGDHkEqavpZG3bqv/XKePXS//9MxK |
64 |
> rq52G8MW2QlYGVFJd8ZR |
65 |
> =5Kdh |
66 |
> -----END PGP SIGNATURE----- |
67 |
> |
68 |
|
69 |
|
70 |
-- |
71 |
Anthony G. Basile, Ph.D. |
72 |
Gentoo Linux Developer [Hardened] |
73 |
E-Mail : blueness@g.o |
74 |
GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA |
75 |
GnuPG ID : F52D4BBA |