Stuart Henderson <st...@openbsd.org> writes: > On 2016/01/26 02:06, Matthew Martin wrote: >> I'd bet the most common use case for tftpd is to serve PXE files or >> similar where the files being served should not be modified. I'm failing >> to find a use case where files need to be overwritten, but new files >> must not be created. > > It's used to allow devices to write files (config, core dumps, etc) > to a tftp server given a known filename, but not allow just anybody > with network access to write random files to the server. > >> Even if such a case did exist, setting the files to >> be overwritten as world-writable and the directory to just >> world-readable would accomplish the same result.
Tim Toady, I don't think that's the point here. >> Patch below provides a reasonable default of read only tftpd, with -c >> allowing writing and creating. Maybe I'm dense but I still can't see what's the point. tftpd *is* read-only by default, only the admin can start tftpd, choose the directory where it looks for files, and set the permissions on those files. It may not work like you thought it did, but it's been working like that since ~30 years - as you mentioned. Changing people's habits isn't a bad thing per se, if it brings a clear benefit. > OK I see some use for -R. Preventing someone from shooting himself in the foot 'cause he messed up permissions? > I'm not sure about making it default, my > opinion could be swayed in either way with good arguments but if done > that the change needs to be communicated clearly (if I am relying on > it for a core dump for some network device, I don't want that to be > quietly disabled by an update). I am actively opposed to removing > the "allow only specific files to be written" feature. I fully agree. -c is for "create", please don't change its semantics. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
