Hi Roland,
Roland Mainz wrote at 03/07/07 15:27:
> Could you add an entry that the matching test (e.g. run setuid script
> when the system's default locale is set to a multibyte locale like
> "en_US.UTF-8") gets added to the regression tests, please ?
I think this is a good idea.
Hi Ales, would
Yes, thanks Ienup. I have put in the details of other locale fixes we
made into the bug description.
Regards,
Suresh
Ienup Sung wrote:
> Thanks very much, Suresh, and this is great.
>
> BTW, I think this isn't just en_US.UTF-8 locale but any other
> locale shared objects needing method shared ob
>
>On Tue, 06 Mar 2007 22:56:25 -0800 Rod Evans wrote:
>> If your dependencies will always live in a fixed location, then
>> $ORIGIN might not be necessary. But, if you want the flexibility of
>> moving the components, but a fall back for secure apps, perhaps
>> having a double runpath is the way
Hi All,
Bug "6532100 en_US.UTF-8.so.3 run time paths should use $ORIGIN and hard
coded locale paths"
is created as the next step for fixing the issue raised in this
discussion thread. Since this light weight fix
is a good opportunity for getting acquainted the OpenSolaris bug fixing
process, we
??: Wed, 07 Mar 2007 03:31:04 +0100
???: Roland Mainz :
> AShiZaWa KaZuNoRi wrote:
> [snip]
> > > Does anyknow have an idea what may be going wrong in this case ? Is
> > > there any restriction for setuid scripts when the system locale is not
> > > "C"/"POSIX" ?
> > >
> > > Quick check at the "trus
Thanks very much, Suresh, and this is great.
BTW, I think this isn't just en_US.UTF-8 locale but any other
locale shared objects needing method shared objects also have the problem,
i.e., some have fixed only and some have $ORIGIN only.
Ienup
Suresh Chandrasekharan wrote at 03/07/07 11:57:
> Hi
Hi,
en_US.UTF-8.so.3 relies on $ORIGIN directive to locate
methods_en_US.UTF-8.so.3.
$ elfdump -d /usr/lib/locale/en_US.UTF-8/en_US.UTF-8.so.3
Dynamic Section: .dynamic
index tagvalue
[0] NEEDED0x552 methods_en_US.UTF-8.so.3
[1] NE
On Wed, 07 Mar 2007 15:08:25 +0100 Casper.Dik at sun.com wrote:
> >does this mean the application will only work setuid with
> >explicit compiled in locale directories?
> No; it means that the locale objects need to have explicit paths
> compiled in themselves.
> The problem is in how /usr/lib/l
>4. Run the script as plain user:
>-- snip --
>$ /home/mytest/setuid_test.ksh
>couldn't set locale correctly
>couldn't set locale correctly
>couldn't set locale correctly
Perhaps this (incorrectly) trips over the stringent locale checks we
have in libc.
>#start PATH=|/usr/xpg6/bin:/usr/xpg4/bin:
On Tue, 06 Mar 2007 22:56:25 -0800 Rod Evans wrote:
> If your dependencies will always live in a fixed location, then
> $ORIGIN might not be necessary. But, if you want the flexibility of
> moving the components, but a fall back for secure apps, perhaps
> having a double runpath is the way to go:
Nicolas Williams wrote:
> On Wed, Mar 07, 2007 at 11:19:04AM +0900, AShiZaWa KaZuNoRi wrote:
> > As /usr/lib/locale/en_US.UTF-8/ is not a trusted directory,
> > ld.so.1 fails to load methods_en_US.UTF-8.so.3.
> >
> > I assume RUNPATH should include /usr/lib/locale/en_US.UTF-8/.
>
> Probably, since
AShiZaWa KaZuNoRi wrote:
[snip]
> > Does anyknow have an idea what may be going wrong in this case ? Is
> > there any restriction for setuid scripts when the system locale is not
> > "C"/"POSIX" ?
> >
> > Quick check at the "truss" logs shows that ksh looks for
> > "methods_en_US.UTF-8.so.3" in /li
Roland Mainz wrote:
[snip]
> - AFAIK the script should run the "id" command as user "root" (maybe I
> am doing something fundamentally wrong or the old /usr/bin/ksh cannot
> handle setuid scripts)
Please ignore this comment/part... I missed the "euid=0" part (I need
either new glasses or more coff
Hi!
I did some experiments with setuid shell scripts in the last hours and
hit a weired problem when the system's default locale is not "C" or
"POSIX":
Steps to reproduce:
1. Set default locale to "en_US.UTF-8":
-- snip --
$ cat /etc/default/init
TZ=Europe/Berlin
CMASK=022
LC_COLLATE=en_US
14 matches
Mail list logo
