On Wed, 2005-11-30 at 13:41, Joerg Schilling wrote: > Bart Smaalders <bart.smaalders at Sun.COM> wrote: > > > My reason for preferring /usr/bin unless there's a name conflict is > > simply this : if users cannot readily find a command, they implicitly > > assume it isn't available. There is basically no benefit obtained from > > "hiding" commands in strange places around the system; once a user > > discovers he needs /usr/wombat/bin once in his path, he adds it - and > > any benefit obtained from sequestering commands there is immediately > > obviated. > > The reason why I still have objections against this idea is that > you may like to create a PATH that includes less binaries and thus seems to > me less dabgerous for administrators.
I'd also like that but unfortunately for the Solaris product we crossed that line when GNOME was dumped into /usr/bin in the name of compatibility with some other platforms. In some cases the better administrator solution is using RBAC and having the admins run as them selves and use pfexec/pf*sh instead (only the things explicitly matched in /etc/exec_attr after a realpath() will run with privilege everything else runs as the normal use. If you want to be really paranoid use a role rather than direct profile assignment and don't allow the role to have the All profile which gives you full control over which commands can be run (including shell escapes by removing proc_exec from commands in the exec_attr entries). However I will be the first to admit this doesn't solve it for all cases and I really wish we hadn't dumped GNOME stuff in /usr/bin: 899 things in /usr/bin on my snv_27 system. However GNOME isn't really the biggest culprit there SUNWcsu alone drops 302 things into /usr/bin. -- Darren J Moffat
