On Thu, 16 Nov 2000, Greg A. Woods wrote:

> If a program can be subverted into even just open()ing and fstat()ing
> random file (and then closing it perhaps) then I'd say there's a design
> flaw in that program (and/or the library subroutines it might call
> upon).
> 
> It seems to mee that the obvious solution to this problem is to
> re-design or remove the feature that's causing the problem in the first
> place, not to re-design the entire system so that this feature can be
> used safely as-is!

Uhm, what makes you think we are re-designing the whole system?

> Changing paradigms and potentially requiring major changes in large
> numbers of security-sensitive programs is an undertaking that must not
> be done without a great deal of careful consideration.  Doing all of
> this just to make one poorly designed feature of questionable utility
> work is almost certainly the wrong approach.

And what makes you think we are proposing this? I have to ask, what
exactly do you think we are proposing? Because from my understanding of
what I proposed, you are on a different page than the rest of us.

> > 	just because you don't use a feature doesn't mean no one else should.
> 
> I want to see people lay down solid requirements for such a feature
> before I jump through twisting burning hoops just to try and make it
> safe to use, and I want them to show how such a feature can be secured
> so that it won't be abused or subverted too!
> 
> As I said before, name-to-location mapping is a highly sensitive system
> service that probably should not be allowed to be subverted, not even by
> local users who purport to know what they're doing.  $HOSTALIASES could
> potentially subvert a privileged application into connecting to the
> wrong host (as could $LOCALDOMAIN).  After all you don't let the user
> specify an alternate name for /etc/passwd, now do you!
> 
> Perhaps if lots of users would cry the blues if these features were
> removed then the best compromise to simply fix privileged and/or set-ID
> programs to ignore them (hopefully by putting such checks directly in
> the library routines which implement these features) and then to live
> with the inconsitencies in program behaviour that will result.

We actually have had this situation for the last few months, and a number
of developers have been unhappy with the result. Which is where this
discussion started.

> Otherwise I would say $HOSTALIASES and $LOCALDOMAIN support just has to
> go away completely and users can either practice their typing skills
> and/or learn to make better use of other UI features that'll help them
> enter fully qualified names where the way the system default search
> features are configured are not to their liking.

As long as you continue to express the inflexability you show above,
people who disagree with you will pursue the only option the situation
leaves them - ignore you. Is that really what you want?

Take care,

Bill