«

I have a Perl script that I want to run as a set-user-ID program. Many
OSes don't allow scripts run as set-user-ID. To make this script
portable, it seems I need to write a C wrapper program that calls exec
or system to give the Perl script the necessary effective permissions.
How can I make the C wrapper program secure? or "more" secure?

The Perl script, which is "-rwsr-xr-x root root" will look at the real
user id and then check a permissions file that is "-rw------- root
root" to determine if the real user can carry out the subcommand to
the script.

Is it futile to attempt to solve my problem with a C wrapper program
around a Perl script? Writing this particular program all in C is
appealing from a purity point of view but I was going to be just
gluing together a bunch of command line tools like wget, chmod, tar
and a parser for YAML. Writing it all in C seems like overkill. If I
write this all in C then I suppose I need to find good libraries to
emulate all of these features.

Any suggestions?

Thanks,
Peter

On 30 Aug 2008 at 18:43, Peter Michaux wrote:
> I have a Perl script that I want to run as a set-user-ID program.
[snip]
> Is it futile to attempt to solve my problem with a C wrapper program
> around a Perl script?

Not at all. There's a discussion in the page got from
perldoc perlsec
and you might be able to find a wrapsuid script in your distribution
that generates a C wrapper automatically.

Peter Michaux wrote:
>
> Any suggestions?
>
comp.unix.programmer

--
Ian Collins.

Peter Michaux <> writes:
> I have a Perl script that I want to run as a set-user-ID program. Many
> OSes don't allow scripts run as set-user-ID. To make this script
> portable, it seems I need to write a C wrapper program that calls exec
> or system to give the Perl script the necessary effective permissions.
> How can I make the C wrapper program secure? or "more" secure?
>
> The Perl script, which is "-rwsr-xr-x root root" will look at the real
> user id and then check a permissions file that is "-rw------- root
> root" to determine if the real user can carry out the subcommand to
> the script.
>
> Is it futile to attempt to solve my problem with a C wrapper program
> around a Perl script? Writing this particular program all in C is
> appealing from a purity point of view but I was going to be just
> gluing together a bunch of command line tools like wget, chmod, tar
> and a parser for YAML. Writing it all in C seems like overkill. If I
> write this all in C then I suppose I need to find good libraries to
> emulate all of these features.

Yes, ask in either a Perl newsgroup or a Unix newsgroup. Standard C
has no concept of accounts or permissions.

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

On Aug 30, 3:03*pm, "Malcolm McLean" <regniz...@btinternet.com> wrote:

> it is reasonable to hardcode paths in a Perl script,
> much less sensible to do so in a C program.

Why is that?

Peter

On 2008-08-31, Richard Heathfield <> wrote:
> Peter Michaux said:
>
>> On Aug 30, 3:03 pm, "Malcolm McLean" <regniz...@btinternet.com> wrote:
>>
>>> it is reasonable to hardcode paths in a Perl script,
>>> much less sensible to do so in a C program.
>>
>> Why is that?
>
> No reason whatsoever. Malcolm is wrong. If you want to hardcode paths in a
> C program, go to it. There will be an impact on portability (because the
> path might not have the same semantics or might not even exist on another
> machine), but that argument applies just as much to the Perl script.
>

Not really - a C program is almost always compiled, which means to change
a hardcoded path one needs to have access to the source code. By nature,
a Perl script is itself the source, meaning that any hardcoded paths are
going to be human-readable and mutable.

--
Andrew Poelstra
To email me, use the above email addresss with .com set to .net

Peter Michaux <> writes:
> On Aug 30, 3:03*pm, "Malcolm McLean" <regniz...@btinternet.com> wrote:
>> it is reasonable to hardcode paths in a Perl script,
>> much less sensible to do so in a C program.
>
> Why is that?

Speaking as both a C programmer and a Perl programmer, I can't think
of any good reason.

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

On Aug 31, 3:18 am, Keith Thompson <kst-> wrote:
> Peter Michaux <> writes:
> > On Aug 30, 3:03 pm, "Malcolm McLean" <regniz...@btinternet.com> wrote:
> >> it is reasonable to hardcode paths in a Perl script,
> >> much less sensible to do so in a C program.
>
> > Why is that?
>
> Speaking as both a C programmer and a Perl programmer, I can't think
> of any good reason.
>

Perl is typically used as a "scripting language", i.e., a glue
language, a language to automate typical tasks, a test driver, etc.

C programs are usually targeted at more serious tasks and are
therefore better structured and developed with maintainability and
reusability in mind. Thus, there's no reason why such a program would
have hard-coded paths, except for example during testing.

Sebastian

"Malcolm McLean" <> writes:
[...]
> That's the answer. Hardcoded paths are a nuisance in a C
> program. Typically C source is thousands of lines long, and the
> executable might be detached from the source for use. So its a big job
> to change the paths.
> On the other hand users expect Perl scripts to contain
> paths. Typically they are quite short and farm out most of the
> "serious" work to other programs. Perl started as a glorified shell
> script, after all.

Perl has its own newsgroups.

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

"Malcolm McLean" <> writes:

> <> wrote in message news:
>> On Aug 31, 3:18 am, Keith Thompson <kst-> wrote:
>>> Peter Michaux <> writes:
>>> > On Aug 30, 3:03 pm, "Malcolm McLean" <regniz...@btinternet.com> wrote:
>>> >> it is reasonable to hardcode paths in a Perl script,
>>> >> much less sensible to do so in a C program.
>>>
>>> > Why is that?
>>>
>>> Speaking as both a C programmer and a Perl programmer, I can't think
>>> of any good reason.
>>>
>>
>> Perl is typically used as a "scripting language", i.e., a glue
>> language, a language to automate typical tasks, a test driver, etc.
>>
>> C programs are usually targeted at more serious tasks and are
>> therefore better structured and developed with maintainability and
>> reusability in mind. Thus, there's no reason why such a program would
>> have hard-coded paths, except for example during testing.
>>
> That's the answer. Hardcoded paths are a nuisance in a C
> program. Typically C source is thousands of lines long, and the
> executable might be detached from the source for use. So its a big job
> to change the paths.
> On the other hand users expect Perl scripts to contain
> paths. Typically they are quite short and farm out most of the
> "serious" work to other programs. Perl started as a glorified shell
> script, after all.

You have just stated that they exist. There is still no good reason why
hard coded paths *should* exist in Perl any more than they should in C.