This content has been marked as final. Show 12 replies
I created a new local userid, ran usermod .. checked /etc/user_attr and ppriv.
Still cannot execute dtrace scripts. The only change was no complaint on usermod command.
The first time the DTrace worked for me, I just edited /etc/user_attr directly as root.
What should I do next?
Edited by: dickdunbar on Jan 26, 2010 5:41 PM
This entry worked for my non-local userid. I just don't know for how long.
---- Then I modified my local id to match ----
Guess what, I don't have privilege.
Oh well, I can make progress on the project without having to understand this.
Very odd that all the documentation on DTrace appears to be incorrect,
or at least not working on my level of Solaris.
Edited by: dickdunbar on Jan 27, 2010 2:45 PM
I have a global NIS userid that logs me into all unix platforms. Doesn't work for Windows (of course).
Part of the value of having a separate "local" userid (one that is authenticated in /etc/passwd),
is you can login to the machine if the network has problems ... NIS server failures, or
NFS automount for my corporate home directory.
The DTrace permissions are controlled by username, not uid.
On Solaris, an NIS enabled account cannot have a duplicate local userid with the same UID/GID.
So I created a local name different from my usual one.
The NIS id works fine now; the local id does not work. The permissions are identical.
The NIS id is the one I want to use anyway; I don't like "one-offs".
It seems I cannot answer my own question.
Add profiles=All to the privileges documented by DTrace publications.
The trick to resolution, doesn't comply with the notion of "least privilege" in Solaris, but it works.
Edited by: dickdunbar on Jan 28, 2010 11:53 AM
Well sounds you have what you want, but there's one statement I shouldn't let go: DTrace makes no particular special use of usernames. All usernames are merely aliases for a uid.
Your solution grants you a kitchen sink of privileges, so it's not surprising that it works. Without knowing more about your remote/local NIS/file setup I wouldn't hazard to offer a least-privileged alternative, but I'm quite sure the problem centers on the way you're applying identities to the system.
Fair enough. If you look up the user_attr man page for field information, though, you'll see this:
user: The name of the user as specified in the passwd(4) database.
So the name given in /etc/user_attr relies on /etc/passwd if you're resolving names with that file. Or it relies on the NIS database, if you're resolving names using that service. This is where I am thinking your system's problematic behavior starts.