On Wed, 2025-05-21 at 11:06 +0200, Sebastian Feld wrote: > On Tue, May 13, 2025 at 3:50 PM Jeff Layton <jlayton@xxxxxxxxxx> wrote: > > > > Back in the 80's someone thought it was a good idea to carve out a set > > of ports that only privileged users could use. When NFS was originally > > conceived, Sun made its server require that clients use low ports. > > Since Linux was following suit with Sun in those days, exportfs has > > always defaulted to requiring connections from low ports. > > > > These days, anyone can be root on their laptop, so limiting connections > > to low source ports is of little value. > > > > Make the default be "insecure" when creating exports. > > I made a poll webpage for our sysadmins about what they think about this change. > > Out of 26 people allowed to vote 24 voted "BAD idea, keep the secure > option the default", and two didn't vote. > > So this is a change which is virtually 100% hated by the people > primarily affected by such a change. > > Polling is all about the question being asked. What was the question? Did it explain that despite the name, the "secure" option offers virtually nothing in the way of security? I'd like at ask these same admins why they care about the source port, because I find it really hard to believe that there are environments out there in 2025 where one simply doesn't have to worry about a random user contacting the server from an unmanaged laptop, or worry about someone rebooting an existing host on the network with a USB stick. Once someone does that, any protection that "secure" gives you is defeated. To wit, if the server is _at_all_ reachable over wifi then this option is likely already worthless. Are there really that many administrators that are running NFS in hermetically-sealed environments? Or are are they just fooling themselves? I think it more likely that most of the people who object to this didn't read beyond the subject line. If this export option were named _anything_ else (e.g. "privilegedport" or something), we wouldn't be having this discussion. -- Jeff Layton <jlayton@xxxxxxxxxx>
