Profile shells

Profile shells pfexec(1) are part of rbac(5) implementation.
They are great but have to be used with caution, upon "best practices".

One important point to highlight, possibly as a best practice, is that built-in rights profiles, prof_attr(4), those located in /etc/security/prof_attr.d and also viewable with profiles(1), may exhibit unexpected behavior if combined with profile shells.

Example:

$ who am i
prime      pts/3        Jun 24 11:26    (:0.0)

$ whoami
prime

$ mkdir test

$ ll -d test
drwxr-xr-x   2 root     staff        117 Jun 24 11:28 test

$ ll -d /tmp
drwxrwxrwt  18 root     sys         2.2K Jun 24 11:28 /tmp

$ pkg info entire | grep Version
       Version: 0.5.11 (Oracle Solaris 11.1.8.4.0)

$ id -a
uid=60004(prime) gid=10(staff) groups=10(staff)

$ getent passwd prime
prime:x:60004:10:Prime Admin:/home/prime:/usr/bin/pfbash

$ getent passwd 60004
prime:x:60004:10:Prime Admin:/home/prime:/usr/bin/pfbash

$ getent user_attr prime
prime::::type=normal;...;profiles=System Administrator;roles=...

As seen above, unexpected side-effects, such as persistent file system attributes (in this case just the ownership), takes place: if the same user (in this case prime) subsequently tries to put something in /tmp/test, it won't succeed because under the System Administrator rights profile, cp(1) or mv(1) don't have the same privilege elevation (uid=0) as mkdir(1).

Still in other words:

Profile shells provides automatic temporary privilege elevation.
The automation is handy, unless there are persistent side-effects.

I'd say profile shells are convenient and recommended only when it can be assured that the side-effects aren't persistent or harmful. As it's impossible to control this for the built-in rights profiles, it's better to avoid combining them.
 
Hence it's still better to explicitly use the traditional pfexec(1) instead of specifying (with the -e option) a profile shell to passwd(1). Indeed, pfexec(1) is still more convenient and safer than the ubiquitous sudo(1m).
  
Nevertheless, in this particular example, I shall investigate if somehow the authorization solaris.file.owner from /etc/security/auth_attr.d/core-os mitigates the issue.