Re: [PATCH] Remove absolute paths from gpg.rc
On Mon, Mar 26, 2007 at 04:27:06PM +0200, Vincent Lefevre wrote:
> On 2007-03-25 08:31:46 +0000, Dave wrote:
> > On Sun, Mar 25, 2007 at 04:11:35AM +0200, Vincent Lefevre wrote:
> > > Now, if software writers make bad decisions, that's the fault and
> > > responsibility of the sysadmin himself? Great!
> >
> > Making a compile-time option isn't a bad decision if the default
> > yields correct behavior.
>
> There first needs to be an agreement on what the correct behavior is.
The nice thing about the UNIX philosophy is that it makes correct behavior
trivial to define for any compliant program. (Unfortunately, as I pointed out
when I first switched from ELM, Mutt combines the functionalities of several
programs already, and so it's not always trivial to define correct behavior in
Mutt. It's still pretty damn easy in most cases, though.)
> > ...but at any rate, a sysadmin is responsible for the software he
> > installs, and if he installs badly written software (i.e., software
> > with bad decisions) without fixing it (i.e., reversing the bad
> > decisions), he's not really doing his job too well. . .
>
> The sysadmin is certainly not responsible if some software has a
> security hole (or a buggy behavior that can lead to a security hole),
> unknown to him.
I'd counter that a sysadmin who installs software should do a background check
to ensure that the thing isn't riddled with security holes unless the program
was specifically requested by the system owner. (Basically, the owner is always
right, as far as the sysadmin is concerned. If the owner wants advice, it's his
own responsibility to ask for it. If the sysadmin can't live with himself and
with his duty to the owner of the system he's in charge of, then he should give
up one or the other.)
> > > > I've already explained several times that the user doesn't own
> > > > the system.
> > >
> > > You don't know what you're talking about.
> >
> > If I'm a user on a corporate server, I don't own the system. I don't
> > suppose you disagree with me there. . .
>
> In *your* case, the doesn't own the system. There are other places
> where the user partly owns the system (well, participates to the
> decisions, at least).
If users on a particular system also have other roles (partners in the entity
that owns the system, voters in an entity with an advisory role to the entity
that owns the system, etc.), those are separate roles. (Basically, if I'm the
owner, sysadmin, and user, on my system, those are all separate roles. I just
happen to be playing all of them. It's the same as the CEO of a small company
often having half a zillion other titles, as well.)
> > > > The physical user is governed by the owner of the system.
> > >
> > > Which is not the system administrator.
> >
> > The owner of the system hires the system administrator to carry out
> > his wishes. I strongly doubt you'd hire a sysadmin who didn't
> > represent your interests to administer your system. In other words,
> > the sysadmin is (an agent of) the owner.
>
> You're playing with words.
I'm trying to reach common ground on basic definitions, since otherwise, we're
speaking different languages.
> But at some places, the user*s* (partly)
> decide what should be done.
Again, the user role isn't a systemwide decision-making role. If on
a particular system, certain other roles are {given to,influenced by}
the physical users on the system, those roles have nothing to do with
the user role. When I speak of users, I'm speaking of a hypothetical
entity with only the user role. With more complex scenarios, entities
can have all sorts of strange combinations of roles. Programs should
always be designed for the simple case, though, since all the more complex
scenarios can be derived from the simple case of complete role separation.
> If some option is configure-time instead
> of run-time, then a part of the users will not be pleased.
Yes, that's a legit argument for eliminating all configure-time options.
Unfortunately, the cost (in programming resources and/or in runtime
resources) of a runtime option is generally higher than the cost of a
configure-time option, so there's a practical advantage to providing
configure-time options in many cases.
> > > > > And what about binary distributions?
> > > >
> > > > By GPL, they must include source.
> > >
> > > What does this change?
> >
> > You've trimmed out some essential context. The GPL ensures that a
> > user can fix and/or reconfigure software, if necessary.
>
> Said otherwise, the user does the sysadmin's job.
Said otherwise, the sysadmin has the domain of setting systemwide policy within
the guidelines of the system owner, while the user has the domain of setting
userwide policy within the guidelines of the sysadmin. If the sysadmin-given
guidelines don't prohibit users from setting up their own software (and the UNIX
platform in particular makes that a good default choice for the sysadmin), then
the user role includes the domain of setting up software (at least) to account
for gaps in the sysadmin-installed software.
> > > The advantage of binary distribution is to
> > > avoid recompilation.
> >
> > Right, but that doesn't prevent you from getting the source and
> > recompiling anyway,
>
> As a user, I already spend to much time recompiling programs on
> various architectures (for various reasons).
Let's analyze the roles in a typical system:
role => purpose
owner => to decide the purpose of the system
sysadmin => to figure out how to make the owner's wishes come true
user => to make the owner's wishes come true (for example, to get work done)
programmer => to build tools
distributor => to build toolsets aimed at system-wide installation
A user who loses efficiency recompiling lots of software on his own is suffering
from a lack of a good sysadmin. Of course, my guess is that you recompile most
of your programs as your sysadmin, not as a user. (Put another way, I assume
you recompile most of your programs and install them in /usr/local or /usr or
something, not in /home/vince or whatever.)
> > if you'd like to reverse a stupid decision made by the distributor.
>
> So, Mutt's configure shouldn't allow stupid decisions.
Mutt's configure is the domain of the programmer. The role of a
programmer is to build tools. Now, a smart decision or a stupid decision
in program configuration on a system-wide basis is the domain of the
sysadmin (delegated from the owner), which he will often subdelegate
to the distributor. A smart decision or a stupid decision in program
configuration for an individual user is the domain of that user. It's
silly to decide as a programmer that a particular decision is stupid for
all distributors, all sysadmins, and all users. Therefore, I'd say that
a decision which is easy for a programmer to leave to somebody closer to
the user should probably be left to somebody closer to the user - i.e.,
somebody who's in a better position to make that decision for the user
who's going to wind up using the program.
That's also the reasoning behind making options runtime, if feasible.
A runtime option is configurable by the user himself, who by definintion
knows exactly what he's trying to do. Not only that, but it's also
reconfigurable by the user on a per-run basis, and even potentially
reconfigurable in the middle of a single run.
> BTW, if Mutt wants to prevent the user from using his own $PATH,
> it should also forbid shell execution and more generally, arbitrary
> program execution (such as the well-known /usr/bin/env wrapper).
Since we've already established that preventing $PATH usage is probably only
useful as part of the boobietrap defense, it'd be nice to provide functionality
to prevent $PATH usage in other ways, but again, probably only if the cost to
provide such a feature is minimal. (Remember, such a feature needs to be
maintained, along with the rest of Mutt.)
- Dave