Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > gnu.bash.bug > #11597

bad handling of error conditions in "type -P'

Show all headers | View raw

There are 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

Back to gnu.bash.bug | Previous | Next | Find similar

Thread

bad handling of error conditions in "type -P' Linda Walsh <bash@tlinx.org> - 2015-10-09 05:17 -0700

csiph-web