On 01/20/2015 12:17 PM, Andreas Gruenbacher wrote:> On 01/20/2015 09:13 PM, H. Peter Anvin wrote: >> I can't remember, but I have a vague recollection that someone >> specifically requested that EACCES be treated the same as ENOENT... > > If that is really necessary then please don't report that condition as > "file not found"; it's really misleading.That is, however, the whole point -- the existence of a inaccessible file should not be visible to the client. This is apparently a security requirement in some environments. -hpa
On Tue, Jan 20, 2015 at 3:55 PM, H. Peter Anvin <hpa at zytor.com> wrote:> On 01/20/2015 12:17 PM, Andreas Gruenbacher wrote: >> On 01/20/2015 09:13 PM, H. Peter Anvin wrote: >>> I can't remember, but I have a vague recollection that someone >>> specifically requested that EACCES be treated the same as ENOENT... >> >> If that is really necessary then please don't report that condition as >> "file not found"; it's really misleading. > > That is, however, the whole point -- the existence of a inaccessible > file should not be visible to the client. > > This is apparently a security requirement in some environments.To me, this feels better either left as-is or implemented as a configuration variable with the default of returning ENOENT but allowing the tftpd to return EACCES if the system administrator feels the benefits outweigh the risks. -- -Gene
On 01/20/2015 01:01 PM, Gene Cumm wrote:> On Tue, Jan 20, 2015 at 3:55 PM, H. Peter Anvin <hpa at zytor.com> wrote: >> On 01/20/2015 12:17 PM, Andreas Gruenbacher wrote: >>> On 01/20/2015 09:13 PM, H. Peter Anvin wrote: >>>> I can't remember, but I have a vague recollection that someone >>>> specifically requested that EACCES be treated the same as ENOENT... >>> >>> If that is really necessary then please don't report that condition as >>> "file not found"; it's really misleading. >> >> That is, however, the whole point -- the existence of a inaccessible >> file should not be visible to the client. >> >> This is apparently a security requirement in some environments. > > To me, this feels better either left as-is or implemented as a > configuration variable with the default of returning ENOENT but > allowing the tftpd to return EACCES if the system administrator feels > the benefits outweigh the risks. >Yes, we can make this an option. -hpa
On 01/20/2015 09:55 PM, H. Peter Anvin wrote:> That is, however, the whole point -- the existence of a inaccessible > file should not be visible to the client. > > This is apparently a security requirement in some environments.Sorry, but people with such stupid requirements just shouldn't be supported. The approach may look alright in a few specific scenarios at the cost of everyone else. Andreas
H. Peter Anvin wrote:> On 01/20/2015 12:17 PM, Andreas Gruenbacher wrote: > > On 01/20/2015 09:13 PM, H. Peter Anvin wrote: > >> I can't remember, but I have a vague recollection that someone > >> specifically requested that EACCES be treated the same as ENOENT... > > > > If that is really necessary then please don't report that condition as > > "file not found"; it's really misleading. > > That is, however, the whole point -- the existence of a inaccessible > file should not be visible to the client. > > This is apparently a security requirement in some environments.If with client you mean a tftp client then it is not the current behavior of tftp-hpa: tftp> get nope Error code 1: File not found tftp> get bar Error code 0: Permission denied Sebastian
On 01/20/2015 02:45 PM, Andreas Gruenbacher wrote:> > Sorry, but people with such stupid requirements just shouldn't be > supported. The approach may look alright in a few specific scenarios at > the cost of everyone else. >That is a pretty harsh statement. That is effectively saying "my use case matters more than anyone else's." -hpa