Date: Fri, 25 Oct 2002 21:25:38 -0700 From: Bakul Shah <bakul@bitblocks.com> To: Terry Lambert <tlambert2@mindspring.com> Cc: Brooks Davis <brooks@one-eyed-alien.net>, freebsd-current@FreeBSD.ORG Subject: Re: pppd not working on latest current 2002-10-20 Message-ID: <200210260425.AAA06488@wellington.cnchost.com> In-Reply-To: Your message of "Fri, 25 Oct 2002 19:05:57 PDT." <3DB9F885.D0A59E87@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> Brooks Davis wrote: > > This isn't going to have an effect on the ability to use kernel ppp for > > other things. The tty orientation of pppd and the outdated, unmodular > > design on ppp(4) have taken care of that. This patch gives people > > the functionality they want (pppd just working) without any major > > entanglements (the whole function is <20 lines). I meant reuse of pppd. From what I remember, pppd does a lot of the control plane stuff (IPCP, CHAP...) which is useful for other ppp-over-foo combinations. In general a different module or set of modules may implement ppp-over-foo so hardwiring the module name in pppd is not a good idea. Now you are probably thinking: "In that case why not just default to if_ppp and otherwise use an environment variable?". This would add complexity and another potential security hole. > > If someone > > wants to make pppd work on arbitrary devices we can deal with that when > > it happens and I frankly doubt it's ever going to since we've got > > netgraph to do that with. Existance of an alternative is not an argument in favor of allowing something to rot since doing so limits your flexibility. Terry writes: > Depending on the value of "sysctl kern.module_path", if the "if_ppp" > module does not exist, and one of the path components is writeable, > then this would permit you to abuse the pppd to load arbitrary modules > into the kernel. Thank you for explicating the security argument! I'll also point out that hardwiring module names makes it harder to experiment with replacement modules (i.e. I may want to develop if_super_duper_ppp). > But by the same token, "mount" and "ifconfig" have the same problems; > on the other hand, unlike pppd, they are not suid root. AFAIK mount does no autoloading (i was using it as another place where one might be tempted to use autoloading). In general any tool (command) that relies on a resource or feature can have the same problem of the resource not existing. Just how far does one go to discover/autoload resources? Should we try to fetch it from a trusted repository? Should we try to compile it if we have the sources? It is a slipper slope. A new programmer next year will assume all the old programmers were fools and to him it will be "obvious" the module sources fetched afresh and compiled. Okay, I am exaggerating. > On general principles, loading modules with commands, rather than the > kernel doing it automatically, is a bad idea. But FreeBSD already > does this in a number of commands, because it lacks a certralized > "feature demand" support facility. Another area for endless debating:-) But don't worry, I'll stop soon! If only the kernel is allowed to load them on demand, there needs to be a way for modules to declare the feature-set they provide and for the kernel to follow administrative policies while autoloading them. > You could also make security arguments on the basis of "what if the > administrator didn't want the machine to be able to be configured > for PPP -- on purpose?" This is a policy argument. Thanks for bringing that up! > As it is, this patch does nothing worse than add to an existing > mess brought about by not having an integrated demand-load facility; > I don't see this as a problem... if there;s a problem, fix it first > in mount and ifconfig, before you complain about this patch. It adds needless complexity. In any case, "complain" is too strong a word! I just pointed out something that I didn't like based on the principles I try to follow when writing software. Consider it in the "leading a horse to water" category:-) If the horse thinks it is just a mirage, that too is fine with me! We can argue about that too. <ducks> I have used up my 2 cents many times over, so over and out! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200210260425.AAA06488>