Date: Fri, 25 Oct 2002 23:42:56 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Bakul Shah <bakul@bitblocks.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: <3DBA3970.26DF3FE9@mindspring.com> References: <200210260425.AAA06488@wellington.cnchost.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Bakul Shah wrote: > 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). Actually, this isn't an issue (I'm assuming that you want it to be named "ppp"). What won't work is autoloading -- you'll get the old module. But if you preload, you can experiment with it fine; it's a different issue if it's not an experiment, though... > > 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). Actually, it does. The standard mount doesn't, but several of the per-FS versions do this. > 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? "All the way"? In the limit, you want things to work without intervention. > 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. Yes. You are. 8-) 8-). > 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. I already talked about this. It's very easy to support. You define an elf section to use for attributes, and the kernel can examine it and know ahead of time. With devfs, you could even register a device for it (in this case, registering an interface is even easier), and then when it's referenced, effectively thunk the real one in place of a loading stub that only knows the name. > > 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! The opposite one is "what it the administrator doesn't want calls at 3 A.M. from idiot users?". 8-). > > 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! It's a good point; the way you will win the argument is by providing kernel autoloading code that makes the autoloading code in user apps no longer necessary... -- Terry 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?3DBA3970.26DF3FE9>