Steve Watt wrote:
In article [EMAIL PROTECTED] you write:
[ snip ]
The solution I am about to implement is based on a custom setuid
syscall, that would allow limited list of processes to obtain root
privileges from a limited set of locations (supposedly, the trusted
ones, originating in the
Greetings, much respected FreeBAS Hackers! :)
I am developing a kernel module that implements a custom syscall and
needs to know from what exact userland address was the call made.
Being concerned about choosing the most correct approach, I turned to
this list for help.
Please provide as much
In article [EMAIL PROTECTED] you write:
[ snip ]
The solution I am about to implement is based on a custom setuid
syscall, that would allow limited list of processes to obtain root
privileges from a limited set of locations (supposedly, the trusted
ones, originating in the httpd's .text
Alfred Perlstein [EMAIL PROTECTED] writes:
erm, can't you point multiple signal handler entries to the same
routine? can't you also make it so that signals aren't defered
or blocked while another handler is executing so you may actually
re-enter the handler before it's complete.
I use good
Dag-Erling Smorgrav [EMAIL PROTECTED] wrote:
Alfred Perlstein [EMAIL PROTECTED] writes:
specifically how you say you increment it, then decrement it,
if you have multiple handlers where one can interupt another
you can have the counter get jumbled.
Not if increment / decrement is atomic.
Wes Peters w...@softweyr.com writes:
On the SPARC, FWIW, the return address is in %i7. What is difficult to
determine (programmatically) is if the function is a normal or leaf function;
different return sequences are used for each.
It doesn't matter; all I need it for is to find the caller's
Alfred Perlstein bri...@rush.net writes:
On 18 Jul 1999, Dag-Erling Smorgrav wrote:
Hmm, I ended up using a global variable which I increment at the
beginning of the signal handler, and decrement at the end.
As long as you make sure the code won't have multiple access
that would work.
On 19 Jul 1999, Dag-Erling Smorgrav wrote:
Alfred Perlstein bri...@rush.net writes:
On 18 Jul 1999, Dag-Erling Smorgrav wrote:
Hmm, I ended up using a global variable which I increment at the
beginning of the signal handler, and decrement at the end.
As long as you make sure the code
Alfred Perlstein bri...@rush.net writes:
erm, can't you point multiple signal handler entries to the same
routine? can't you also make it so that signals aren't defered
or blocked while another handler is executing so you may actually
re-enter the handler before it's complete.
I use good ol'
Dag-Erling Smorgrav d...@flood.ping.uio.no wrote:
Alfred Perlstein bri...@rush.net writes:
specifically how you say you increment it, then decrement it,
if you have multiple handlers where one can interupt another
you can have the counter get jumbled.
Not if increment / decrement is atomic.
On 18 Jul 1999, Dag-Erling Smorgrav wrote:
Alfred Perlstein [EMAIL PROTECTED] writes:
This looks like what you are doing is trying to grab the data on the
stack before "log" which is the return address.
Yes. It actually works :)
I
On 18 Jul 1999, Dag-Erling Smorgrav wrote:
Alfred Perlstein [EMAIL PROTECTED] writes:
On 18 Jul 1999, Dag-Erling Smorgrav wrote:
Alfred Perlstein [EMAIL PROTECTED] writes:
I doubt this is
at all portable and may fail because of
Alfred Perlstein wrote:
On 17 Jul 1999, Dag-Erling Smorgrav wrote:
Is there any (evidently non-portable) way of determining a function
instance's return address? I have an idea or two that involves the
return address and dladdr(). The code I currently use looks like this:
This looks
Alfred Perlstein bri...@rush.net writes:
This looks like what you are doing is trying to grab the data on the
stack before log which is the return address.
Yes. It actually works :)
I doubt this is
at all portable and may fail because of
On 18 Jul 1999, Dag-Erling Smorgrav wrote:
Alfred Perlstein bri...@rush.net writes:
This looks like what you are doing is trying to grab the data on the
stack before log which is the return address.
Yes. It actually works :)
I doubt
Alfred Perlstein bri...@rush.net writes:
On 18 Jul 1999, Dag-Erling Smorgrav wrote:
Alfred Perlstein bri...@rush.net writes:
I doubt this is
at all portable and may fail because of optimizations and ABI, such
as archs that store the
On 18 Jul 1999, Dag-Erling Smorgrav wrote:
Alfred Perlstein bri...@rush.net writes:
On 18 Jul 1999, Dag-Erling Smorgrav wrote:
Alfred Perlstein bri...@rush.net writes:
I doubt this is
at all portable and may fail because of
Alfred Perlstein wrote:
On 17 Jul 1999, Dag-Erling Smorgrav wrote:
Is there any (evidently non-portable) way of determining a function
instance's return address? I have an idea or two that involves the
return address and dladdr(). The code I currently use looks like this:
This looks
Is there any (evidently non-portable) way of determining a function
instance's return address? I have an idea or two that involves the
return address and dladdr(). The code I currently use looks like this:
int
log_print(log_t *log, char *fmt, ...)
{
char date[32], str[MAX_LOG_LINE];
On 17 Jul 1999, Dag-Erling Smorgrav wrote:
Is there any (evidently non-portable) way of determining a function
instance's return address? I have an idea or two that involves the
return address and dladdr(). The code I currently use looks like this:
int
log_print(log_t *log, char *fmt, ...)
20 matches
Mail list logo
