Poison Bit <poison...@gmail.com> wrote: > Why filter to those in /etc/shells ? I mean... the filter should be > applied by the system :)
Mainly because it's a convenient list of "real" shells, and some of the remote service applications require a shell to be in that list. FTP is one such that springs to mind. As a counter example, /bin/false is a possible shell but it doesn't provide a particularly useful environment for the user. You could change the scriptlet to check for the 7th column being either empty or an executable file if you preferred. > But neither of both codes take in mind if there is sudo in the system, > and what is gained in its config. I don't recall the OP mentioning access via sudo. (BICBW.) > Also, neither of both codes think about ForceCommand in ssh... So I > maybe listed as /bin/bash, but I me be able only of run /usr/bin/cal > once as my shell and get kicked. ForceCommand requires an interactive shell-like login on the target, so I don't believe that's relevant here. Chris -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/uad3u8x037....@news.roaima.co.uk
