| 1 |
Nikos Chantziaras <realnc@×××××.com> wrote: |
| 2 |
|
| 3 |
> > But please first explain what "option" you are talking about. |
| 4 |
> |
| 5 |
> An option to forcibly enable and disable support. If enabled, the build |
| 6 |
> system assumes the library is there. If disabled, it assumes the |
| 7 |
> library is not there (even if it is). If not given at all, do |
| 8 |
> autodetection. |
| 9 |
|
| 10 |
This may be an option for things that really are optional. |
| 11 |
|
| 12 |
Libcap however is not something optional but needed to support a basic security |
| 13 |
feature. |
| 14 |
|
| 15 |
> One thing I've learned in software development is that "the user knows |
| 16 |
> best." If the user has the library installed, he should still be able |
| 17 |
> to tell you "yes, I have that lib, but I don't want you to use it", and |
| 18 |
> vice versa. |
| 19 |
|
| 20 |
As mentioned above, we are talking about a library to support basic security |
| 21 |
features, so the code from that library would really belong into libc. Since |
| 22 |
Linux now by default supports fcaps in the filesystems, cdrecord would open |
| 23 |
a security hole if the library was not used - without that library, cdrecord |
| 24 |
cannot even see that is has been called with additional privileges that need |
| 25 |
to be removed before the main code is executed. |
| 26 |
|
| 27 |
Do you really like to go into a security risk with your eyes open? |
| 28 |
|
| 29 |
Jörg |
| 30 |
|
| 31 |
-- |
| 32 |
EMail:joerg@××××××××××××××××××××××××.de (home) Jörg Schilling D-13353 Berlin |
| 33 |
js@××××××××××××.de (uni) |
| 34 |
joerg.schilling@××××××××××××××××.de (work) Blog: http://schily.blogspot.com/ |
| 35 |
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily |
Archives