On Wed, Aug 27, 2008 at 6:57 AM, Steve Dickson <SteveD@xxxxxxxxxx> wrote: > > > Chuck Lever wrote: >> Hi guys- >> >> I was wondering if anyone ever builds nfs-utils with RESTRICTED_STATD >> undefined these days. It seems totally insecure to do. Is it still >> necessary to keep this? >> >> It would be easier to understand, update, and test the logic in >> utils/statd/monitor.c (IPv6-wise) if we could remove the unused parts of >> this code. >> >> I propose removing RESTRICTED_STATD, leaving in the secure version of >> the code permanently and removing the insecure parts that are left out >> when RESTRICTED_STATD is undefined. >> >> Thoughts? > I seem to remember enabling RESTRICTED_STATD cause problems with > portmapper and kernel interactions which causes me to turn it off... > So if we do permanently turn on the code, let make sure lock recover > and such still work... Enabling RESTRICTED_STATD is the current default. Disabling RESTRICTED_STATD allows remote hosts to register notification requests with rpc.statd. It's called out in a 1999 CERT advisory. I don't think any distribution would ever want to allow this. However, there may be some folks who build rpc.statd themselves for specialized applications may miss it if we pull it out. -- "If you simplify your English, you are freed from the worst follies of orthodoxy." -- George Orwell -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
