https://bugzilla.mindrot.org/show_bug.cgi?id=3478
--- Comment #2 from Colin Watson <[email protected]> --- (In reply to Darren Tucker from comment #1) > Arbitrarily failing syscalls that do not normally fail has been the > source of serious security vulnerabilities in the past (eg > CVE-2000-0506). That's why the default action is "kill" instead of > "fail" and others are considered on a case by case basis. I don't think this is _not_ an issue, and I agree it requires care - that's why I included the umask case - but I think we have more problems the other way round. > I think that's a pretty good argument that glibc should provide an > interface that is usable by applications that does not have that > layering violation. Even just being able to specify the filters by > libc function name rather than syscall name would help a lot, > however I suspect doing that would be challenging given that the > kernel and glibc are developed independently. Sure, but there seems little appetite to do this with actually-existing Linux and glibc (I certainly don't have time for that sort of multi-year project), so where does that leave us? Tracking syscall minutiae forever doesn't seem appealing. -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug. _______________________________________________ openssh-bugs mailing list [email protected] https://lists.mindrot.org/mailman/listinfo/openssh-bugs
