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
Hi Dick -
Add the Primary Administrator to your /etc/user_attr entry:
You could also add root as a role if it is defined as one in this file, but it's not necessary here.
No Joy. It still tells me I don't have privilege.
One of the suggestions in a (now closed) topic was that the entries were cached.
I rebooted the machine ... it still isn't working.
( I hate to run as root; guess I'll have to )
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
Hm, what's this about local/non-local userids?
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.
Are the uid on the system and the one given you by NIS authentication the same? If not, that could explain why perfectly correct settings aren't working.
What does the id command give you on that system when you run it?
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.
Well, I'm just following the DTrace docs.
The identifier in the attr file is a name, not a UID.
If you want to figure out what Dtrace does with that, you could do what I did:
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.