I think you've uncovered a bug in SRSS, although
it would need some discussion.
SRSS doesn't update
/etc/dt/config/{Xstartup,Xsetup,Xreset}, and it
probably should so that you can make a copy and
apply customizations yourself.
What you should do is to go ahead and make this
copy and apply your customizations. You might
want to surround them with comments so you can
easily find them in future. If you upgrade SRSS,
you'll need to again copy this file to
/etc/dt/config and apply your customizations,
unfortunately. Or you can edit
/etc/dt/config/Xstartup to remove the code
between:
# Start SUNWut
and
# End SUNWut
and copy that block over from the new
/usr/dt/config/Xstartup. Make sure that the
updated SRSS has started up at least once
before doing this, since this block gets
re-inserted on every SRSS startup.
I'll file a bug to make sure this gets tracked/addressed
in the product.
-Bob
Note: The views and opinions expressed in this
mail are strictly mine. The contents of this mail
have not been reviewed or approved by Sun
Microsystems.
fitra budi anggoro wrote:
Hi Bob, Otto,
First, I just checked /usr/dt/config/Xstartup file, but it said something like
this :
************** DO NOT EDIT THIS FILE **************
/usr/dt/config/Xstartup is a factory-default file and will
be unconditionally overwritten upon subsequent installation.
Before making changes to the file, copy it to the configuration
directory, /etc/dt/config. You must also update the startup
resource in /etc/dt/config/Xconfig.
$XConsortium: Xstartup.src /main/cde1_maint/3 1995/10/03 17:50:05 gtsang $
do i have to check with Xconfig too?
Second, if I add the following line before $start SUNWut,
printf "%s\t%s-%s-%s %s:%s\n" $LOGNAME `date +%Y` `date +%m` `date +%d` `date
+%H` `date +%M`
where I got $TOKEN id?
thanks & regards,
Fitra
Bob Doolittle <[EMAIL PROTECTED]> wrote: 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 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
---------------------------------
Yahoo! Groups gets better. Check out the new email design. Plus there’s much more to come.
------------------------------------------------------------------------
_______________________________________________
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
