Harry,
I tried entering your email in the subscription form, and there was no
problem. I guess there was a typo in the address during your previous
attempt to subscribe. If you clicked through the confirmation message, you
should be subscribed now.
-Albert
Sorry for the last post, the original mail comes here, and explains...
Message original
Sujet: [osol-discuss] [OT] Openindiana mailing list
Date : Wed, 20 Oct 2010 21:16:49 -0500
De :Harry Putnam
Organisation : Still searching...
Pour : opensolaris-discuss@opensolaris.o
On 10/21/10 11:50, Harry Putnam wrote:
Thank you, but that was understood. As mentioned in my post I hoped
to find an openindiana enthusiast here as there are many lurking or
posting here.
Hoping to get to an openindiana reader who may know what I need to do
since I'm rejected from that list as
> On 10/20/10 3:39 AM, casper@sun.com wrote:
> >
> >
> >> I had a few minutes today to try an
> experiment, and I'm afraid
> >> the idea of having ld always generate a
> PT_SUNWSTACK is a non-starter.
> >>
> >> The problem is that it overrides the behavior of
> 'set noexec_user_stack=1'
> >
Jim Grisanzio
writes:
> hi ... opensolaris.org does not host that mailing list. Our lists are
> here: http://mail.opensolaris.org/mailman/listinfo. We used to have a
> list called indiana-discuss, but that list is not longer used and the
> archives are here:
> http://mail.opensolaris.org/pipermail
On 10/21/10 11:16 AM, Harry Putnam wrote:
Sorry for the ot, but hoped to find an openindiana enthusiast who can
coach me a bit.
Trying to subscribe to openindiana-discuss mailing list at:
http://openindiana.org/mailman/listinfo/openindiana-discuss
My request is rejected with:
"Your subsc
Sorry for the ot, but hoped to find an openindiana enthusiast who can
coach me a bit.
Trying to subscribe to openindiana-discuss mailing list at:
http://openindiana.org/mailman/listinfo/openindiana-discuss
My request is rejected with:
"Your subscription is not allowed because the email addre
Octave Orgeron wrote:
> OpenIndiana is another option like so many now for x86 such as Belinix,
> Schillix, Nextenta,
> etc.
>
> I just find it distasteful for anyone to shoot down someone's questions or to
> even suggest they switch to another OS. If you feel that way, you shouldn't
> be
On 10/20/10 3:39 AM, casper@sun.com wrote:
I had a few minutes today to try an experiment, and I'm afraid
the idea of having ld always generate a PT_SUNWSTACK is a non-starter.
The problem is that it overrides the behavior of 'set noexec_user_stack=1'
in /etc/system, and can therefore
In that case, let me revise my earlier proposal:
ADDR_HEAP would apply to the entire heap, current and future.
ADDR_STACK would alter future behavior (both for main stack and
by invalidating stackprot as previously mentioned, for thread stacks),
but for the sake of gcc trampolines and the complex
>Looks to me like
>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libc/port/threads/thr.c
>
>checks sysconf(_SC_STACK_PROT) and honors it. The only problem is
>that it caches the return value (static variable stackprot), which
>would have to be invalidated by the mprotect() wr
>
>
> >Which does the PT_SUNWSTACK header apply to?
>
> It sets the fields in the proc structure which
> defines the stack
> protection.
>
> >I'm not sure what point there would be in per-thread
> >control; if any one thread in an address space is
> exploitable,
> >the whole address space is p
>Which does the PT_SUNWSTACK header apply to?
It sets the fields in the proc structure which defines the stack
protection.
>I'm not sure what point there would be in per-thread
>control; if any one thread in an address space is exploitable,
>the whole address space is potentially corruptible.
Or you can file a bug and wait until Solaris 11 Express to push for a fix. It's
not like someone would fix your bugs right away with the way things were before
Oracle. I still have bugs filed from years ago that haven't been fixed in ON.
Like any other OS, if you want your bug fixed, it has to
>
>
> >I picture this somehow as being just a bit more
> functionality added to mprotect(2):
> >
> >/* following magic to identify operating on that
> segment, rather than
> > * a particular address
> > */
> >#define ADDR_STACK (void *) (-1)
> >#define ADDR_HEAP (void *) (-2)
> >
> >mprotect(ADDR
>How does the trampoline work on architectures which have noexec bit
>for stack by default, like sparcv9?
A long time ago, I made some changes to gcc; I'm not sure if the changes
are still in current gcc, but what happens is that we run mprotect() on
the parts of the stack where we need to exec
How does the trampoline work on architectures which have noexec bit
for stack by default, like sparcv9?
Olga
On Wed, Oct 20, 2010 at 2:26 PM, wrote:
>
>
>>I picture this somehow as being just a bit more functionality added to
>>mprotect(2):
>>
>>/* following magic to identify operating on that
>I picture this somehow as being just a bit more functionality added to
>mprotect(2):
>
>/* following magic to identify operating on that segment, rather than
> * a particular address
> */
>#define ADDR_STACK (void *) (-1)
>#define ADDR_HEAP (void *) (-2)
>
>mprotect(ADDR_STACK, 0, (PROT_READ|PR
>
>
> >I had a few minutes today to try an experiment,
> and I'm afraid
> >the idea of having ld always generate a PT_SUNWSTACK
> is a non-starter.
> >
> >The problem is that it overrides the behavior of
> 'set noexec_user_stack=1'
> >in /etc/system, and can therefore quietly allow
> programs
"In short, the Oracle executives said that the open source, community-driven
OpenSolaris project as conceived and built by Sun Microsystems five years ago
is dead."
A quote from http://www.theregister.co.uk/2010/08/13/opensolaris_is_dead/
If the pen drive isn't detected, then perhaps another OS
Hello,
I need to know if FTP has support for multibyte languages.
Meaning, if the locale is set to be multibyte languages like Japanese/
Chinese, does FTP/FTPD in solaris support it?
With Regards,
Shilpa.
--
This message posted from opensolaris.org
__
>I had a few minutes today to try an experiment, and I'm afraid
>the idea of having ld always generate a PT_SUNWSTACK is a non-starter.
>
>The problem is that it overrides the behavior of 'set noexec_user_stack=1'
>in /etc/system, and can therefore quietly allow programs that would
>not previ
22 matches
Mail list logo
