OttoM is right.
Remember this is all happening during login time.
dtlogin runs the login GUI greeter with UID root
initially. Later in the login process it changes the
UID to the user who has authenticated, and just
before it creates the user's session/desktop it
executes the Xsession.d scripts - with the
UID of the user.
So using an Xsession.d script is not secure since
it runs as the user, which means any file it writes
must be writable by random users, which means
random users can alter its contents if they're
dishonest.
An alternative is to run the script from
/usr/dt/config/Xstartup, which is executed *before*
dropping the UID to the user (i.e. it is executed while
the UID is still root). So you can log to a file that is
writable only by root, and that's secure because nobody
else can mess with it's contents.
If you do this, be sure to put your changes to Xstartup
before the comment beginning with:
# Start SUNWut
The stuff after this is modified by Sun Ray software on
every restart.
If you want all the details about the login process and
what gets executed when, it's all on the dtlogin man page,
but be forewarned that there's a lot of complexity there
and it will take a few readings to absorb it all.
-Bob
fitra budi anggoro wrote:
Hi Otto,
I amnot really get it about :
"The next-easiest place I can think of is during Xstartup,
which runs as root after the user has logged in. The user
can't interfere with it and it can log to a root-only destination"
Can explain more detail about it? I am new about it
Thanks
Fitra
ottomeister <[EMAIL PROTECTED]> wrote: On 6/21/06, Bob Doolittle wrote:
#!/bin/sh
utwho -c | nawk -v TOKEN=$SUN_SUNRAY_TOKEN '
$2 == TOKEN { printf ( "User: %s Token: %s\n", $3, $2 ) }
'
If this is executing during session startup then why does it
need to run 'utwho'? It's running as the user, so 'id' is all
you need. You could even 'echo $LOGNAME'. But,
unfortunately, it's (by design) very easy for a user to
interfere with the execution of an Xsession.d script so
they're not great for doing things that absolutely have to
work correctly.
Also, because an Xsession.d script runs as a normal user,
the place it's logging to has to be writeable by that user.
This means that the user can write to the logging mechanism
at any time, which means that he can write garbage into it.
Maybe even delete or truncate it, if it's just a file.
If the users are malicious or even just mischievous then
you need to be careful about how you create and log this
information. You might decide that an Xsession.d script
just isn't the appropriate solution.
The next-easiest place I can think of is during Xstartup,
which runs as root after the user has logged in. The user
can't interfere with it and it can log to a root-only destination.
OttoM.
__
ottomeister
Disclaimer: These are my opinions. I do not speak for my employer.
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
---------------------------------
Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great rates
starting at 1ยข/min.
------------------------------------------------------------------------
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
