| 1 |
Il 31/07/2012 21:27, Michał Górny ha scritto: |
| 2 |
> On Tue, 31 Jul 2012 15:16:34 -0400 |
| 3 |
> Rich Freeman<rich0@g.o> wrote: |
| 4 |
> |
| 5 |
>> On Tue, Jul 31, 2012 at 10:56 AM, Ian Stakenvicius<axs@g.o> |
| 6 |
>> wrote: |
| 7 |
>>> Although that is true, it would be -WAY- too slow to generate said |
| 8 |
>>> list via equery/q* helpers; I think that's where the |
| 9 |
>>> extended-attributes and/or cache idea comes into play. |
| 10 |
>> I agree. This needs to be high-performance when it comes to |
| 11 |
>> individual file access. If it takes 10 seconds per build to populate |
| 12 |
>> some database or set up a bazillion bind mounts that isn't the end of |
| 13 |
>> the world, but if it takes an extra 0.1 seconds every time a file is |
| 14 |
>> read that could add up VERY fast on a large build. |
| 15 |
> I'd be more afraid about resources, and whether the kernel will be |
| 16 |
> actually able to handle bazillion bind mounts. And if, whether it won't |
| 17 |
> actually cause more overhead than copying the whole system to some kind |
| 18 |
> of tmpfs. |
| 19 |
If testing show that bind mounts are too heavy we could resort to |
| 20 |
LD_PRELOAD a library that filter the acces to the disk, |
| 21 |
or to rework sandbox to also hide w/o errors some files, |
| 22 |
with an appropriate database (sys-apps/mlocate come to mind) every |
| 23 |
access will have negligible additional cost compared to that of |
| 24 |
rotational disks. |
| 25 |
>> Ideally I'd like to see the same thing extended to run-time, and short |
| 26 |
>> of writing some entirely new security model into the kernel or taking |
| 27 |
>> namespaces to a whole new level, part of me thinks that |
| 28 |
>> auto-generating SELinux policies might be the solution, so that the |
| 29 |
>> existing mechanism can be extended. |
| 30 |
>> |
| 31 |
>> The mad scientist in me keeps thinking up crazy schemes so that |
| 32 |
>> package collisions can be handled by each package just seeing whatever |
| 33 |
>> it wants to see - maybe the entire filesystem looks different |
| 34 |
>> depending on what app you use. Then I realize that bash is an |
| 35 |
>> application, and how on earth would a human make sense of a system |
| 36 |
>> where no file has any stable identifier other than maybe a |
| 37 |
>> content-hashed key. Then that makes me wonder why we link to |
| 38 |
>> libraries by filename anyway, when we could just give each library a |
| 39 |
>> GUID and version, and maybe a more general identifier for cases where |
| 40 |
>> you have alternate implementations. |
| 41 |
>> |
| 42 |
>> But, as long as we're still just running Gentoo on Unix-like OSes |
| 43 |
>> maybe tweaking the jail is a good place to start... |
| 44 |
>> |
| 45 |
>> Rich |
| 46 |
>> |
| 47 |
> |
| 48 |
> |
Archives