1 |
On 10/22/2013 03:39 PM, Michael Orlitzky wrote: |
2 |
> -----BEGIN PGP SIGNED MESSAGE----- |
3 |
> Hash: SHA1 |
4 |
> |
5 |
> On 10/22/2013 03:08 PM, Allan Wegan wrote: |
6 |
>>> When you emerge something with a bazillion files, the install |
7 |
>>> wrapper (and thus the python interpreter) get launched that many |
8 |
>>> times. It's the startup time that kills it. |
9 |
>> |
10 |
>> Should that PAX markings not only be neccessary for a few |
11 |
>> hand-selected binaries that refuse to work with secure-by-default |
12 |
>> settings? I remember setting PAX-markings by hand (a year or so |
13 |
>> ago) for a few binaries that would else crash with Grsec loglines. |
14 |
>> I did not had the impression, that there are much of them (that |
15 |
>> where mostly games, i admit). |
16 |
> |
17 |
> Yes, and it should be possible to "write down" which binaries got |
18 |
> pax-marked, and only use the python install wrapper for those |
19 |
> particular files. |
20 |
> |
21 |
> But, there is an underlying problem that it would be nice to solve at |
22 |
> the same time. It should be possible to set any sort of xattrs (not |
23 |
> just PAX!) in an ebuild and have them correctly copied to the live |
24 |
> filesystem during an emerge. |
25 |
|
26 |
My motivation here was beyond just user.pax.flags. Right now the |
27 |
install.py wrapper only does XT_PAX flags, ie the user.pax.flags |
28 |
namespace, but it should be able to do any extended attribute namespace. |
29 |
I'm trying to pave the way for full end-to-end extended attribute support. |
30 |
|
31 |
For this to work, we have to handle the |
32 |
> case where a developer (or an upstream makefile) calls setfattr |
33 |
> manually on some files. When FEATURES="xattr" is set, portage uses the |
34 |
> wrapper to install /every/ file, ostensibly for this case. |
35 |
|
36 |
I know, that's the real catch-22 here. The wrapper can't even decide if |
37 |
it even needs to run unless it runs. Which means python has already |
38 |
been invoked with all its overhead. |
39 |
|
40 |
I'm not sure how to trap this within portage itself. There is a |
41 |
pre-wrapper wrapper at |
42 |
|
43 |
/usr/lib/portage/bin/ebuild-helpers/xattr/install |
44 |
|
45 |
which is a bash script. Maybe I can trap it there and shave some time |
46 |
off the python wrapper running. Else, I'll just have to rewrite |
47 |
install.py in C. |
48 |
|
49 |
> |
50 |
> The other way to handle it would be to check whether or not some file |
51 |
> has xattrs, and use the regular 'install' if it doesn't. But how do |
52 |
> you implement that? You'd either have to hack portage, or write some |
53 |
> sort of wrapper... |
54 |
|
55 |
How *do* you implement that? it would solve the above catch-22. |
56 |
|
57 |
> |
58 |
> There's already a hack in portage to support xattrs, so maybe that |
59 |
> would work, who knows. I'm in over my head here. |
60 |
|
61 |
Portage has to preserve xattrs at lots of points. The previous work |
62 |
just preserved xattrs in copying from $D to $ROOT (ie during qmerge when |
63 |
the stuff in /var/tmp/portage/.../image is copied to the actual file |
64 |
system). What I added was to preserve xattrs when doing install, ie |
65 |
when installing from $S into $D. The problem there is that coreutils' |
66 |
install does NOT preserve xattrs and does not even have a flag to turn |
67 |
on the preserving of xattrs :( To top it off, we have to selectively |
68 |
decide which xattr namespaces to preserve and which not to because |
69 |
selinux labels were not to be copied. I could produce a patch but |
70 |
core-system was leary of changing the default behavior of install. The |
71 |
*obvious* solution was to write a python wrapper ... little did we know |
72 |
how slow it would be! I don't feel so bad because I bounced this off of |
73 |
others and no one suspected it either :( |
74 |
|
75 |
> |
76 |
> |
77 |
> -----BEGIN PGP SIGNATURE----- |
78 |
> Version: GnuPG v2.0.20 (GNU/Linux) |
79 |
> |
80 |
> iQIcBAEBAgAGBQJSZtRsAAoJEBxJck0inpOiz7AQAJIW8wrNorRl8YOjAOlTpoq/ |
81 |
> rerZ2IIpyYYg6uB9fotEcJYtmiinClX4Yf3crl2tyqLZLlQJUFrIM+A90LdNAdXY |
82 |
> wYbf5R9HpMxhNsTVKb4sP/ErZzktVOf26kyjzPlql+P/ICk0NYO+YgAswJI4b5L9 |
83 |
> trVuraFPwPQGEDDEq5Ep8+9Mm6rBgAj95HlZHIChKVR0zB7jKL372z3QemeFS1sO |
84 |
> Hc7YDZvlwb1U9Ab/EK7qy1aqTZg6Zrzn/wslyZo+tpnJ+aCJENXGDXWh678LDDTP |
85 |
> BnKXsTjNkMXs+fmRfkL2ivIJNs8dYIlcTZ4rBotdBgXQ+fusRuyKXQe3CbyjMzjV |
86 |
> 7V8s+aMj31QN29MbQ33zDIEdDyuhulXv4SpxZQfYyRn7ZBdmz2AxSABySQA7DzvJ |
87 |
> OVwe6jRd7Zm272STBj0Agnf2ct6F0KRsC+gPl2COY9y+sV90BzquCsDYB4Z6ybX4 |
88 |
> 6Ttl/oAxVYjWZNu669TFxeiiga0FhjLVOTvaCJdXrva97iZsssjJFPJcCVSx/IKQ |
89 |
> gu2WbZDX5yx0/TYNRIrqZ8MDB49sCMSLktvjJoOoEydaBDCv6X3y+zvVuR/OCElV |
90 |
> DHdNRi25shztbQTZamgQdQLKOluTEPZ4gkAKH5jUHrg70cfQMG1HXMZFqC64aSi8 |
91 |
> lUkJE3WYhuXJX9S6RvDE |
92 |
> =G/D/ |
93 |
> -----END PGP SIGNATURE----- |
94 |
> |
95 |
|
96 |
|
97 |
-- |
98 |
Anthony G. Basile, Ph. D. |
99 |
Chair of Information Technology |
100 |
D'Youville College |
101 |
Buffalo, NY 14201 |
102 |
(716) 829-8197 |