> Which again re-enforces that system_noshell() *is* intended to be a
> replacement for system(3C).
>
> I have not problem with providing a variant of system(3C) that is more
> secure. However I'm not convinced that a new symbol - and thus changes
> to existing code to use it. Is the best way
Sumanth Naropanth wrote:
> The system_noshell() set of functions are _not_ designed to replace
> system(3C), posix_spawn(3C) or exec() family of functions. They are
> designed to be a *secure alternative* to system(3C) while provide the
> ease of use of system(3C). posix_spawn() and fork()/exec()/w
Sumanth Naropanth wrote:
> + Unrelated to posix_spawn(), but system_noshell*() functions mirror
>system(3C) behavior of ignoring SIGINT and SIGQUIT, but they do it
>only in the child making the functions MT-safe unlike system(3C).
Could you be more specific?
when calling system(), the
"Garrett D'Amore" wrote:
> Ditto. This is a solution looking for a problem, and it does nothing
> (IMO) to address the situations where use of system() is either
> completely safe, or required due to use of shell constructs such as
> redirection. It's also not portable, so it won't be useful
>Sumanth Naropanth wrote:
>> Darren J Moffat wrote on 05/29/09 05:59:
>>> What happens with open file descriptors ?
>>>
>>
>> The system_noshell*() functions will call posix_spawn(3C) with a NULL
>> 'file_actions' argument, so the file descriptors open in the calling
>> process remain open in the
Sumanth Naropanth wrote:
> Darren J Moffat wrote on 05/29/09 05:59:
>> What happens with open file descriptors ?
>>
>
> The system_noshell*() functions will call posix_spawn(3C) with a NULL
> 'file_actions' argument, so the file descriptors open in the calling
> process remain open in the child, e
Casper.Dik at Sun.COM wrote:
> >> >> None of our current shells evaluates the IFS environment variable.
> >> >
> >> >The Bourne Shell (bin/sh) does.
> >> >
> >>
> >>
> >> Not in Solaris; it was fixed before Solaris 7 (bug 4077929)
> >
> >Why do you believe this?
>
>
> Have you ever tested /bin/sh?
>Casper.Dik at Sun.COM wrote:
>
>>
>> >Casper.Dik at sun.com wrote:
>> >
>> >>
>> >> > If not used carefully, the system(3C) function may be responsible for
>> >> > the following security concerns:
>> >> >
>> >> > + Execution of the command is affected by the PATH, IFS and other
>> >> >enviro
Casper.Dik at Sun.COM wrote:
>
> >Casper.Dik at sun.com wrote:
> >
> >>
> >> > If not used carefully, the system(3C) function may be responsible for
> >> > the following security concerns:
> >> >
> >> > + Execution of the command is affected by the PATH, IFS and other
> >> > environment va
Joerg Schilling wrote:
> Casper.Dik at Sun.COM wrote:
>
>
>>> Casper.Dik at sun.com wrote:
>>>
>>>
> If not used carefully, the system(3C) function may be responsible for
> the following security concerns:
>
>+ Execution of the command is affected by the PATH, IF
>Casper.Dik at sun.com wrote:
>
>>
>> >If not used carefully, the system(3C) function may be responsible for
>> >the following security concerns:
>> >
>> > + Execution of the command is affected by the PATH, IFS and other
>> > environment variables.
>>
>> None of our current shel
John.Zolnowsky at sun.com wrote:
>
> Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI
> This information is Copyright 2009 Sun Microsystems
> 1. Introduction
> 1.1. Project/Component Working Name:
>system_noshell
> 1.2. Name of Document Author/Supplier:
>Author: Sumant
Casper.Dik at sun.com wrote:
>
> > If not used carefully, the system(3C) function may be responsible for
> > the following security concerns:
> >
> > + Execution of the command is affected by the PATH, IFS and other
> >environment variables.
>
> None of our current shells eval
John.Zolnowsky at sun.com wrote:
>
> Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI
> This information is Copyright 2009 Sun Microsystems
> 1. Introduction
> 1.1. Project/Component Working Name:
> system_noshell
> 1.2. Name of Document Author/Supplier:
> Author: Su
> If not used carefully, the system(3C) function may be responsible for
> the following security concerns:
>
>+ Execution of the command is affected by the PATH, IFS and other
> environment variables.
None of our current shells evaluates the IFS environment variable.
John.Zolnowsky at Sun.COM wrote:
> Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI
> This information is Copyright 2009 Sun Microsystems
> 1. Introduction
> 1.1. Project/Component Working Name:
>system_noshell
> 1.2. Name of Document Author/Supplier:
>Author: Sumant
What happens with open file descriptors ?
--
Darren J Moffat
Joerg Schilling wrote on 05/29/09 12:47:
> Sumanth Naropanth wrote:
>
>> + Unrelated to posix_spawn(), but system_noshell*() functions mirror
>>system(3C) behavior of ignoring SIGINT and SIGQUIT, but they do it
>>only in the child making the functions MT-safe unlike system(3C).
>
> Cou
On Fri, May 29, 2009 at 05:38:20AM -0700, John.Zolnowsky at Sun.COM wrote:
> PROPOSED SOLUTION:
I like this a lot, but there are a few small improvements that need to
be made.
> The system_noshell_x() allows variable number of arguments and can be
> used to supply argument strings con
Casper.Dik at Sun.COM wrote on 05/29/09 06:11:
>> system_noshell(const char *abs_path);
>>
>> system_noshell_x(const char *abs_path, uint_t flags, const char *arg0,
>> ... /* const char *argn, (char *)0 */);
>>
>> system_noshell_xv(const char *abs_path, uint_t flags,
>>
Roland Mainz writes:
> John.Zolnowsky at sun.com wrote:
> > system_noshell_x(const char *abs_path, uint_t flags, const char
> > *arg0,
> > ... /* const char *argn, (char *)0 */);
> >
> > system_noshell_xv(const char *abs_path, uint_t flags,
> > char *const
Casper.Dik at Sun.COM wrote:
>> Sumanth Naropanth wrote:
>>
>>> Darren J Moffat wrote on 05/29/09 05:59:
>>>
What happens with open file descriptors ?
>>> The system_noshell*() functions will call posix_spawn(3C) with a NULL
>>> 'file_actions' argument, so the fi
Darren J Moffat wrote on 05/29/09 05:59:
> What happens with open file descriptors ?
>
The system_noshell*() functions will call posix_spawn(3C) with a NULL
'file_actions' argument, so the file descriptors open in the calling
process remain open in the child, except for those having the FD_CLOEX
Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI
This information is Copyright 2009 Sun Microsystems
1. Introduction
1.1. Project/Component Working Name:
system_noshell
1.2. Name of Document Author/Supplier:
Author: Sumanth Naropanth
1.3 Date of This Document:
24 matches
Mail list logo
