Many thanks for discussing the ping issue of shmux, James, Gary and Nico! James Carlson wrote: > Gary Winiger writes: > >>> -bash-3.2$ ppriv -De fping -h >>> fping[18609]: missing privilege "net_icmpaccess" (euid = 201400, syscall >>> = 230) needed at secpolicy_net_icmpaccess+0x24 >>> fping: can't create raw socket : Permission denied >>> >>> As a result, it seems not necessary to file a bug against fping. >>> >> Are you then saying that shmux will pfexec /usr/bin/fping so >> that administrators with the Network Management Rights Profile >> can use shmux to call fping? >> No. I meant we do not need to file a bug against fping to make it setuid because it had been integrated as a RBAC command already.
And I had thought we could just integrate the shmux "as is", ie. remain 'fping' and '-p' option, two reasons: - ordinary users(who do not have permission to run fping) still can use all other features of shmux except the optional '-p', moreover, even with '-p', the output of shmux will still be expected. - after all, for root or those users who had been granted the permission, they can run shmux with '-p' option as they will. > > Having to grant a rights profile just so that people can use this > shmux utility strikes me as an extremely poor answer. > > There's no clear reason this utility needs to use fping. It likely > shouldn't be using it. The reason fping has restricted access on > Solaris (and isn't either setuid or in any "normal" profile) is that > it's considered _dangerous_. The regular 'ping' utility appears to > have all of the functionality that this shmux feature needs, and it > doesn't require the user to have any special privileges. > > I strongly recommend either: > > - Fixing this utility so that it invokes "ping". > > or: > > - Just removing the silly "-p" option. > > > > On Fri, Mar 06, 2009 at 10:38:38AM -0500, James Carlson wrote: > > A tool like shmux that can't talk to its targets in parallel so that one > unreachable target need not slow everything down is not worthy of > integrating. If shmux can do that then it doesn't need a -p option. > > Thus I'm for "removing the silly "-p" option." > > I'd like to remove the '-p' option by adding a patch, if you all think it is better for integrating shmux to solaris. > (shmux does need a connect timeout option, Yes, it has! Current shmux has three types of timeout: timeout of ping, timeout of test and timeout of execution, please refer to the shmux manpage(http://web.taranis.org/shmux/man/shmux.1.html): Before executing the specified /command/, *shmux* will option-? ally ping each target to ensure that it can be reached, and/or run a dummy test /command/ to make sure that the tar-? get not only is alive, but that it is possible to cleanly execute a command on it. Both these tests are typically run with a fairly short timeout to quickly dismiss unavailable targets rather than waiting for the standard (longer) network timeout. *-P* /timeout/ Defines the initial target ping timeout in mil-? liseconds, see /fping(8)/. (Implies *-p*.) *-T* /timeout (default 15s)/ Defines the test timeout in seconds. (Implies *-t*.) *-C* /timeout/ Specify a timeout for the command being executed on targets. This should be a number followed by a time unit. The following are valid time units: s(econds), m(inutes), h(our), d(ays), w(eeks). > but that's another story. > I've not looked to see if has one.) > > Nico > --
