[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: make distcheck fails for simple

From: Bob Friesenhahn
Subject: Re: make distcheck fails for simple
Date: Sat, 2 Jul 2005 15:04:38 -0500 (CDT)

On Sat, 2 Jul 2005, Roger Leigh wrote:

Thanks.  I read this, but I still don't think this is the correct
solution.  I can see this would work well for a user-extensible
program, such as the GIMP, which has system and user plugin and module

For system-level programs, there is only one install location.  In the
case of CUPS, the directories for data, backend binaries and filter
binaries are fixed.  Being able to specify an alternate location with

In this case CUPS must be broken software. Fixed at install time is considerably different than "hard coded" in the source code.

In the case of programs using Linux-PAM (libpam), /etc/pam.d and
/etc/security are the only places you could install authentication
service configuration files.  It doesn't make sense to have any other
place for e.g. SSH configuration, and it would be a security issue to
boot.  Even if a user builds their own SSH, it will still need to look

Sorry, my SSH configuration files are not under /etc. There were good reasons to put them somewhere else (besides the fact that OpenSSH defaults to elsewhere). I don't see how relocating these files could be a security issue. Putting sensitive files in non-default locations actually improves security. If /bin/sh could be moved, then system security would improve immensely, but unfortunately, it is inconvenient to move.

There are very few programs on a Unix system that I would call "system-level programs". Certainly the process with PID=0 and (possibly) 'init' fall into this category. Everything else is just application software. In fact, it should be possible to use an alternate program in the place of 'init'. One person's "system-level program" is another person's relocatable/replaceable application.

It would be wrong to assume that the world is bound by Linux conventions.

Bob Friesenhahn
GraphicsMagick Maintainer,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]