From: TJ S. <tj...@ca...> - 2015-10-08 15:17:43
|
> I'm not asking for my conclusions to be second guessed. No, but since you did not provide enough information, anything we could do to help would, by necessity, be speculation, and would have to involve second guessing. For instance, the fact that you are running custom code was not something you mentioned, and that sort of thing can have unexpected side effects/impacts. > I know exactly how Unix permissions and ownership work. There is an actual problem. I believe you, but to get to the root of the problem, you might try being less combative with your responses. I am trying to help, and am not looking for an argument. Attitudes like the above, though, make me feel that my attempts to help are not actually wanted in this case. > Something very strange is going on. I debugged it down to the bare metal, > where the proftpd code does an open() call on the file, and it is very > simple : it is allowed inside proftpd, it is disallowed outside (with a > bit of independent C code). This is with the exact same path, chroot, > UID, GID, EUID, EGID, even SUID, SGID. As far as I know, there are no > other factors that determine access, except for things like SELinux, but > there is no security context associated with the test file. Another possible factor is the use of POSIX ACLs. Are you possibly using a kernel, and filesystem, that have POSIX ACL support? And using a proftpd compiled with the --enable-facl configure option? TJ |