Hi.
2008/10/2 Ceri Davies <ceri at submonkey.net>:
> On Thu, Oct 02, 2008 at 08:31:41AM +0200, Michael Schmarck wrote:
>> Hi.
>>
>> 2008/10/1 David Bustos <David.Bustos at sun.com>
>> >
>> > Quoth Michael Schmarck on Wed, Oct 01, 2008 at 02:20:21PM +0200:
>> > > As I'm not root, I of course cannot write to /dev/msglog.
>> > >
>> > > What's the proper remedy to this problem on Solaris 10?
>> > > Chmod 0666 /dev/../devices/pseudo/sysmsg at 0:msglog?
>> >
>> > That would probably work, but then anybody could write to msglog. You
>>
>> Of course. And for that reason, chmod 0666 isn't a real
>> solution. :)
>
> You could give that user the file_dac_write privilege, and then drop it
> with ppriv after the write to msglog.
Hm.
beta at sys06 ~ $ ppriv -l | grep file_dac_write
file_dac_write
Ie. the user "beta" on system "sys06" already has
this priv. And in my SMF manifest, I have:
[...]
<exec_method name='start' type='method'
exec='/etc/svc/method/foo.sh' timeout_seconds='60'>
<method_context working_directory='/opt/apps/beta'>
<method_credential user='beta'/>
</method_context>
</exec_method>
[...]
In the script "/etc/svc/method/foo.sh", I have:
#!/sbin/sh
# [...]
# Source SMF convenience functions and return value definitions.
[ -r "/lib/svc/share/smf_include.sh" ] && . "/lib/svc/share/smf_include.sh"
# [...]
echo "Error! Unknown action!" 2>&1 | smf_console
# [...]
I added the " 2>&1 | smf_console", because in smf_include.sh,
there is:
# [...]
# smf_console
#
# Use as "echo message 2>&1 | smf_console". If SMF_MSGLOG_REDIRECT
is
# unset, message will be displayed to console. SMF_MSGLOG_REDIRECT
is
# reserved for future use.
#
smf_console () {
/usr/bin/tee ${SMF_MSGLOG_REDIRECT:-/dev/msglog}
}
# [...]
And now my expectation is, that this should simply work
as documented.
But, as we see, it doesn't work.
But maybe I'm just doing something wrong - how is
"smf_console ()" supposed to be used, in case a
non-root user runs this? And a non-root user may
easily run this, if "smf_console" is used in a method
script, which gets invoked by service manager, because
of a
svcadm enable svc:/foo
call.
Thanks a lot,
Michael
