|
Key
This line was removed.
This word was removed. This word was added.
This line was added.
|
Changes (3)
View page history| {warning:title=Warning}This page is under construction - do not use!{warning} |
| {anchor:top} h1. {anchor:CHP-SEC} Security |
... |
| [Top|#top] h2. {anchor:CHP-SEC-2} Privileged Use of DTrace |
| Users with any of the three DTrace privileges may enable probes provided by the {{dtrace}} provider (see [Chapter 17, dtrace Provider FIX|Title]), Provider|dtrace Provider]), and may use the following actions and variables: |
| |Providers|{{dtrace}}| | | |Actions|{{exit}}|{{printf}}|{{tracemem}}| |
... |
| |Address Spaces|User| | | The {{dtrace_user}} privilege provides only visibility to those processes to which the user already has permission; it does not allow any visibility into kernel state or activity. With this privilege, users may enable the {{syscall}} provider, but the enabled probes will only activate in processes to which the user has permission. Similarly, the {{profile}} provider may be enabled, but the enabled probes will only activate in processes to which the user has permission, never in the Solaris kernel.\\ |
| \\This privilege permits the use of instrumentation that, while only allowing visibility into particular processes, can affect overall system performance. The {{syscall}} provider has some small performance impact on every system call for every process. The {{profile}} provider affects overall system performance by executing every time interval, similar to a real-time timer. Neither of these performance degradations is so great as to severely limit the system's progress, but system administrators should consider the implications of granting a user this privilege. Refer to [Chapter 21, syscall Provider FIX|Title] Provider|syscall Provider] and [Chapter 19, profile Provider FIX|Title] Provider|profile Provider] for a discussion of the performance impact of the {{syscall}} and {{profile}} providers. |
[Top|#top] |
... |