On Tue, May 07, 2002 at 04:26:32PM -0500, Manoj Srivastava wrote: > Indeed, the one pro of having libexec that no one seems to > have mentioned is mount options: if /etc/libexec is a separate file > system, I can mount /lib with noexec, and only have the exec mount > flag for libexec, and it adds a little more hassles to a croacker who > has broken in. I am not sure whether this is enough to succefully > advocate for the inclusion of libexec. The problem with this benefit is the small number of people who would directly benefit from it - how many people do you know with seperate partitions for /usr/lib? I don't know many. Although, from a purely paranoia standard, I can envision creating one for this very purpose and think it is worth considering for that purpose. Having sheer paranoia levels of security being available to those who would use them is a goal I think we can all agree is not a bad thing. I'm not sure I buy the stuff about binaries which the user doesn't need to run not belonging in /usr/lib because they're not traditional libraries though. Traditionally all sorts of crap has gone into /usr/lib and still does today. Even our menu system does this, for example. And being Debian native code, one would reasonably expect both locations to work and packages to start depending on a new version of menu which supports looking for entries in a more suitable location under /usr/share. The fact is though that /usr/lib _is_ used in ways which we would not normally expect (or want sometimes) and this is just the way things are. I just don't see the motivation to fight for this change here since it really does not make that big of a deal at the end of the day. -- Joseph Carter <firstname.lastname@example.org> I N33D MY G4M3Z, D00D!!!!111!! (Just ... don't ask) <Overfiend> partycle: I seriously do need a vacation from this package. I actually had a DREAM about introducing a stupid new bug into xbase-preinst last night. That's a Bad Sign.
Description: PGP signature