Hi Darren,
I don't know why you dislike pfexec script so much :-) , I just think
after I move brasero.bin to /usr/lib/brasero, /usr/bin looks clean. I
have a suggestion before Solaris provides runtime upgrade privileges
methods. Since more and more applications will probably depend on
pfexec, create the following directory structure (use brasero as example),
/usr/bin/brasero link to /usr/lib/pfexec_dependent_base_dir/pfexec_wrap,
the real brasero binary is delivered to
/usr/lib/pfexec_dependent_base_dir/bin/,
pfexec_wrap is a script to run pfexec
/usr/lib/pfexec_dependent_base_dir/bin/* $*.
If it is not acceptable, see my following revision of this case.
>> 3) The program will be run as root (if I correctly understand what gksu
>> does) which means that when browsing for files it will see a different
>> home directory (root's) and may not even be able to access the proper
>> user's home directory if on NFS. The application may also look different
>> due to themeing configuration , recent files list etc. From a usability
>> point of view this isn't very nice.
>
> gksu on OpenSolaris has been modified (though strangely the man page
> doesn't talk about this - I'll file a man page bug) to first look to
> see if the user has an RBAC profile for the command being run if it
> does then it uses pfexec(1).
Yes, gksu has been modified, so this solution is acceptable to me.
Revised the spec like:
1) continue using gksu through panel menu,
2) keep the following settings and updated to not use pfexec script:
prof_attr:
Desktop CD User:::Access CD for desktop user:
Console User::::profiles=Desktop CD User
exec_attr:
Desktop CD User:solaris:cmd:::/usr/bin/brasero:privs=sys_devices
If users want to run brasero from a terminal, they have to explicitly
use gksu to load it. Any /usr/lib/libbrasero-media.so consumer
applications also require gksu.
lin
