On 29/04/13 16:09, Joerg Schilling wrote:
Nikos Chantziaras <[email protected]> wrote:
But please first explain what "option" you are talking about.
An option to forcibly enable and disable support. If enabled, the build
system assumes the library is there. If disabled, it assumes the
library is not there (even if it is). If not given at all, do
autodetection.
This may be an option for things that really are optional.
Libcap however is not something optional but needed to support a basic security
feature.
I thought it is optional, since it was mentioned that cdrtools can be
built and ran without it?
Unless you mean "recommended" instead of "required." "Recommended"
means it's still optional.
One thing I've learned in software development is that "the user knows
best." If the user has the library installed, he should still be able
to tell you "yes, I have that lib, but I don't want you to use it", and
vice versa.
As mentioned above, we are talking about a library to support basic security
features, so the code from that library would really belong into libc. Since
Linux now by default supports fcaps in the filesystems, cdrecord would open
a security hole if the library was not used - without that library, cdrecord
cannot even see that is has been called with additional privileges that need
to be removed before the main code is executed.
Do you really like to go into a security risk with your eyes open?
You don't know what my intentions are. I might be doing testing,
debugging, who knows what. It's the "trying to be smarter than the
user" thing. The defaults of course would be to built the software in a
sane, secure way. Only users who know what they're doing would disable
that, and they'd have their reasons.
