Nikos Chantziaras <[email protected]> wrote: > > 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?
If you call something that is needed in order to prevent security holes "optional", you may call it optional. > Unless you mean "recommended" instead of "required." "Recommended" > means it's still optional. Is something to grant security optional or required? > > 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. Would you call someone who shoots himself into the foot "smart"? Recent Linux kernels support fcaps in the filesystems and "somebody" evil, who knows what he does may even set up fcaps on executable files when the related support-software is not installed, just because the unstable kernel interfaces are accessible from libc. Do you like people to be able to open security holes? Jörg -- EMail:[email protected] (home) Jörg Schilling D-13353 Berlin [email protected] (uni) [email protected] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
