I've run across several problems with how type -P returns errors.
1) if a file isn't executable, type returns it anyway in
ls -l /sbin/scat
-r--r--r-- 1 root root 245663 Nov 19 2013 /sbin/scat
type -P scat
/sbin/scat 2) if a file is inaccessible, type still returns it an answer for the path of an executable named 'scat1':
ls -l /sbin/scat1
---------- 1 root root 245663 Nov 19 2013 /sbin/scat1
type -P scat1
/sbin/scat1 3) bash "knows better" because it doesn't do this in "posix mode" 4) if it doesn't find the file it returns a status code meaning 'EPERM' rather than 'ENOENT'. (ENOENT No such file or directory (POSIX.1)) This is true in normal mode or posix mode. 5) if the file is executable for root, it is still return as an answer for 'type -P':
ls -l /sbin/scat2
---x------ 1 root root 245663 Nov 19 2013 /sbin/scat2
type -P scat2
/sbin/scat2 6) if bash is in posix mode it will find '/sbin/scat2' only if the owner is root (good), BUT for a non-root user, a return code of '1' is return whether it the file exists or not. NOTE: by 'coincidence' on linux, 1=EPERM, which would be correct for /sbin/scat2, but it also returns '1' for the "ENOENT" case. 7) if the file is NOT owned by root, type -P returns the alien-owned file (this seems like it would be a security risk -- but it is also in the kernel, so bash behaving differently, though correct, would be inconsistent with the insecure behavior of the kernel:
ls -l /sbin/ucat2
---x--x--- 1 nobody nogroup 245663 Nov 19 2013 /sbin/ucat2
type -P ucat2 #(normal user)
# type -P ucat2 #(root user is unprotected) /sbin/ucat2 Proposals: 1) It seems the non-posix mode should parallel the posix mode in this case. 2) type should return 'EPERM' if it finds an executable owned by someone else that isn't allowed execution by the caller. 3) if no file with any executable bits is set it should return status 'ENOENT'. 4) Ideally root would not behave differently from the normal user case, since ownership by a non-priviledged user might indicate a security problem, HOWEVER, this should be brought to the attention of the kernel folks for an explanation why root can execute files owned by suspect users. Perhaps Bash being different in this case would be a best course, as it is doing a path seach, while in the kernel case, it should only be allowed if an absolute path was given (with no PATH search). I regard this as rather broken, as it gives useless, wrong and insecure answers depending on the case. I also think bash, having had it's behavior changed due to posix rules should be using posix standard errno names, doesn't that make sense? Cheers, L. Walsh
