RE: custom slush

The main slush thread is given a uid of 0 (guest) since it does not
represent any user.  Once a user logs in, the thread that is created for
that session is assigned that users id.

To directly answer your question, the uid of a constructor derived from the
Slush class would have a uid of 0.  You can easily change this behavior by
overriding the getCurrentUID of the Slush class.  Something like the
following should work:  (I didn't try to compile this so please excuse any
silly mistakes.)

bool inMyConstructor = false;

class MyNewSlush extends Slush
{
	public MyNewSlush()
	{
		inMyConstructor = true;

		...	// Put your code here.

		inMyConstructor = false;
	}

	public byte getCurrentUID()
	{
		// See if we are in the same thread as
		if(inMyConstructor)
		{
			return adminUID; //You can return whatever uid you
want right here.
		}
		else
		{
			return super.getCurrentUID();
		}
	}
}

This is just one of a few different ways to achieve the same result.  You
could also save a reference to the current thread at the beginning of your
constructor (myThread = Thread.currentThread()) and use this to determine
which id to return from the getCurrentUID method.

--Lorne


> -----Original Message-----
> From: Bernhard Boser [mailto:boser-aFE07iDfcCIb0cFwG/[email protected]]
> Sent: Monday, June 14, 2004 3:09 PM
> To: 'Lorne Smith'; tini-6tN4nzCoH/[email protected]
> Cc: Bernhard Boser
> Subject: RE: [TINI]custom slush
> 
> 
> Lorne,
> 
> Thank you for the quick reply. Can you clarify the following for me:
> 
> What are the permissions (uid) of in the constructor of a 
> class derived from
> Slush? 
> 
> Presently, I am "stealing" that thread for my application. 
> Perhaps this is
> not so fine and it's easy to start a separate thread, but 
> since that one
> apparently would inherit (after calling registerThread) the 
> permissions from
> the thread that executed the Slush constructor, those permissions are
> relevant in any case.
> 
> Bernhard
> 
> -----Original Message-----
> From: Lorne Smith [mailto:Lorne.Smith-6tN4nzCoH/[email protected]] 
> Sent: Monday, June 14, 2004 8:41 AM
> To: 'boser-aFE07iDfcCIb0cFwG/[email protected]'; tini-6tN4nzCoH/[email protected]
> Subject: RE: [TINI]custom slush
> 
> Bernhard,
> 
> For every thread you create from within the Slush process, 
> you need to call
> the registerThread(Thread thisThread) method that is part of the
> com.dalsemi.slush.Slush class.  Call this method immediately after
> instantiating the new thread, but before you start it.  This 
> allows the OS
> to give the new thread the same permissions as its parent.  
> Not calling this
> method leaves the permissions for the thread set to the 
> default value of 0
> (the guest id).
> 
> --Lorne
> 
> > -----Original Message-----
> > From: tini-admin-6tN4nzCoH/[email protected] 
> > [mailto:tini-admin-6tN4nzCoH/[email protected]]On Behalf Of
> > Bernhard Boser
> > Sent: Sunday, June 13, 2004 9:26 PM
> > To: tini-6tN4nzCoH/[email protected]
> > Cc: Bernhard Boser
> > Subject: [TINI]custom slush
> > 
> > 
> > I've extended slush to run my own code. Problem: my code has 
> > no file write
> > privileges. Apparently, these can be enabled in Slush with 
> > the following
> > command:
> > 
> > 	userIDByThreadID.put(
> > 		Thread.currentThread(), 
> > 		new Byte((byte)adminUID));
> > 
> > Unfortunately, userIDByThreadID is declared private in 
> Slush and hence
> > inaccessible in my derived class. I could of course modify 
> > Slush directly,
> > but prefer not do so if possible.
> > 
> > What is the "correct" way to set file write permissions in 
> > custom Slush
> > extensions?
> > 
> > Thanks,
> > Bernhard
> > 
> > _______________________________________________
> > TINI mailing list
> > TINI-6tN4nzCoH/[email protected]
> > To UNSUBSCRIBE, edit your profile, or see list archives:
> > http://lists.dalsemi.com/mailman/listinfo/tini
> > 
> 
_______________________________________________
TINI mailing list
TINI-6tN4nzCoH/[email protected]
To UNSUBSCRIBE, edit your profile, or see list archives:
http://lists.dalsemi.com/mailman/listinfo/tini