By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,640 Members | 1,600 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,640 IT Pros & Developers. It's quick & easy.

C set-user-ID program wrapper for Perl script and security

P: n/a
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
Aug 30 '08 #1
Share this Question
Share on Google+
24 Replies


P: n/a
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.

Aug 30 '08 #2

P: n/a
Peter Michaux wrote:
>
Any suggestions?
comp.unix.programmer

--
Ian Collins.
Aug 30 '08 #3

P: n/a

"Peter Michaux" <pe**********@gmail.comwrote in message
>
Any suggestions?
The C program to execute a perl script froma system call to the Perl
interpreter is trivial. However I doubt that UNIX would be so easily fooled.

Writing the Perl script in C is more difficult, because Perl scripts tend to
make use of operations that are hard to implement in C. Also it is
reasonable to hardcode paths in a Perl script, much less sensible to do so
in a C program.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

Aug 30 '08 #4

P: n/a
Peter Michaux <pe**********@gmail.comwrites:
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) ks***@mib.org <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"
Aug 31 '08 #5

P: n/a
On Aug 30, 3:03*pm, "Malcolm McLean" <regniz...@btinternet.comwrote:
it is reasonable to hardcode paths in a Perl script,
much less sensible to do so in a C program.
Why is that?

Peter
Aug 31 '08 #6

P: n/a
Peter Michaux said:
On Aug 30, 3:03 pm, "Malcolm McLean" <regniz...@btinternet.comwrote:
>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.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Aug 31 '08 #7

P: n/a
On 2008-08-31, Richard Heathfield <rj*@see.sig.invalidwrote:
Peter Michaux said:
>On Aug 30, 3:03 pm, "Malcolm McLean" <regniz...@btinternet.comwrote:
>>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 ap*******@wpsoftware.com
To email me, use the above email addresss with .com set to .net
Aug 31 '08 #8

P: n/a
Andrew Poelstra said:
On 2008-08-31, Richard Heathfield <rj*@see.sig.invalidwrote:
>Peter Michaux said:
>>On Aug 30, 3:03 pm, "Malcolm McLean" <regniz...@btinternet.comwrote:

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.
Fair point - but let's compare like with like. If you're shipping source,
ship source, in which case the C program is just as human-readable as the
Perl script (and possibly *more* so, given typical Perl scripts!), and
just as mutable. All you need then is a C compiler (which is analogous to
the Perl interpreter).

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Aug 31 '08 #9

P: n/a
Peter Michaux <pe**********@gmail.comwrites:
On Aug 30, 3:03*pm, "Malcolm McLean" <regniz...@btinternet.comwrote:
>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) ks***@mib.org <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"
Aug 31 '08 #10

P: n/a
On Aug 31, 3:18 am, Keith Thompson <ks***@mib.orgwrote:
Peter Michaux <pe**********@gmail.comwrites:
On Aug 30, 3:03 pm, "Malcolm McLean" <regniz...@btinternet.comwrote:
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

Aug 31 '08 #11

P: n/a

<s0****@gmail.comwrote in message news:
On Aug 31, 3:18 am, Keith Thompson <ks***@mib.orgwrote:
>Peter Michaux <pe**********@gmail.comwrites:
On Aug 30, 3:03 pm, "Malcolm McLean" <regniz...@btinternet.comwrote:
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.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

Aug 31 '08 #12

P: n/a
"Malcolm McLean" <re*******@btinternet.comwrites:
[...]
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) ks***@mib.org <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"
Aug 31 '08 #13

P: n/a
"Malcolm McLean" <re*******@btinternet.comwrites:
<s0****@gmail.comwrote in message news:
>On Aug 31, 3:18 am, Keith Thompson <ks***@mib.orgwrote:
>>Peter Michaux <pe**********@gmail.comwrites:
On Aug 30, 3:03 pm, "Malcolm McLean" <regniz...@btinternet.comwrote:
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.
Aug 31 '08 #14

P: n/a

"Richard" <rg****@gmail.comwrote in message
>
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.
The alternative to hardcode paths is softcoded paths. However Perl is
already an evolved shell script. The major thing that the shell does is to
allow the user to specify files by path. By demanding softcoded paths in
Perl you are taking away the natural facilities of the shell, and creating a
dependency.
On the other hand C is a compiled language. It is not possible to edit the
source and run, one must recompile. There might well be several executables
on different machines derived from the one C source. So updating the C
program when paths change is a major nuisance.

Basically, write everything that doesn't need hardcoded paths in C, then
write a Perl script to drive your C programs, with the paths coded into the
Perl script where it is too much of a burden on the user to put them on the
commandline.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

Aug 31 '08 #15

P: n/a
"Malcolm McLean" <re*******@btinternet.comwrites:
"Richard" <rg****@gmail.comwrote in message
>>
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.
The alternative to hardcode paths is softcoded paths. However Perl is
err, quite.
already an evolved shell script. The major thing that the shell does
is to allow the user to specify files by path. By demanding softcoded
As do all file commands in C.
paths in Perl you are taking away the natural facilities of the shell,
and creating a dependency.
Rubbish. No one is demanding anything. Its just that hardcoded paths are
often questionable. One should calculate them based on querying the
system or constructing relative paths. "Hard coded" here I take to mean
a specific URL/link with root fixed.
On the other hand C is a compiled language. It is not possible to edit
Thanks for that too ....
the source and run, one must recompile. There might well be several
Uh huh. Recompile eh?
executables on different machines derived from the one C source. So
updating the C program when paths change is a major nuisance.
Updating ANY source when paths change is a nuisance. Hence you TRY to
make the sure the program has the information it needs to construct a
proper path regardless of system and install location.
Basically, write everything that doesn't need hardcoded paths in C,
then write a Perl script to drive your C programs, with the paths
coded into the Perl script where it is too much of a burden on the
user to put them on the commandline.
I don't necessarily disagree with that. But again, where hard coded
paths can be avoided in PERL/Python scripts too then do so. Hard coded
paths have been the bane of Linux adoption, for example, for years since
half the hacked up shell scripts to install certain SW assumes a certain
distro only to be run on a different distro where the paths are
nonsense.
Aug 31 '08 #16

P: n/a
On Aug 31, 8:51*am, Richard Heathfield <r...@see.sig.invalidwrote:
Andrew Poelstra said:
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.

Fair point - but let's compare like with like. If you're shipping source,
ship source, in which case the C program is just as human-readable as the
Perl script (and possibly *more* so, given typical Perl scripts!), and
just as mutable. All you need then is a C compiler (which is analogous to
the Perl interpreter).
Why do I always get this sinking feeling whenever I need to download
something and it's only available as C sourcecode instead of a ready-
to-go executable? Especially in some god-foresaken format like tar and
gz?

It's like the difference between buying, say, an amplifier ready-made,
and getting just the schematics, a pcb, and most of the parts.

By the time you've put it all together, and you're very lucky, it /
might/ just work.

--
Bartc
Aug 31 '08 #17

P: n/a
On 31 Aug 2008 at 15:23, Bart wrote:
Why do I always get this sinking feeling whenever I need to download
something and it's only available as C sourcecode instead of a ready-
to-go executable? Especially in some god-foresaken format like tar and
gz?

By the time you've put it all together, and you're very lucky, it /
might/ just work.
Because it's been 10 or 15 years since you last tried it?

Seriously, the huge majority of software distributed nowadays as source
uses the GNU autotools - type the three famous lines

../configure
make
make install

and It Just Works.

Aug 31 '08 #18

P: n/a
On Aug 31, 2:04*am, "Malcolm McLean" <regniz...@btinternet.comwrote:
<s0s...@gmail.comwrote in message news:
On Aug 31, 3:18 am, Keith Thompson <ks...@mib.orgwrote:
Peter Michaux <petermich...@gmail.comwrites:
On Aug 30, 3:03 pm, "Malcolm McLean" <regniz...@btinternet.comwrote:
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.
This doesn't seem like a very compelling argument to me. If a Perl
script is installed in /usr/local/bin like a compiled C program would
be, then no one should be editing the Perl file anyway. It should be
configured during the "perl Makefile.pl" step anyway.

How can a C program not contain at least one path compiled in? That
path being /etc/myapp or whatever sysconfdir was set to during ./
compile. All the other paths can be specified in the config file in /
etc/myapp but if the app cannot find the config it can't really get
going.

Peter
Aug 31 '08 #19

P: n/a
Peter Michaux wrote:
On Aug 30, 3:03 pm, "Malcolm McLean" <regniz...@btinternet.comwrote:
>it is reasonable to hardcode paths in a Perl script,
much less sensible to do so in a C program.

Why is that?
Two reasons:

1) Perl is almost always interpreted, while C is almost always compiled.
If a hardcoded path is incorrect, it is much less work to change it in
a Perl script (which just requires a text editor) than to change it in C
program (which you may not have the source for, and requires a full
development environment to recompile if you do).

2) Perl is used almost exclusively on POSIX systems, whereas C is used
across a much, much wider range of platforms. POSIX systems have a
common filesystem layout and pathname structure, which means it is much
less likely that a hardcoded pathname is incorrect in the first place.

S
Aug 31 '08 #20

P: n/a
In article <sl*******************@nospam.invalid>,
Antoninus Twink <no****@nospam.invalidwrote:
>On 31 Aug 2008 at 15:23, Bart wrote:
>Why do I always get this sinking feeling whenever I need to download
something and it's only available as C sourcecode instead of a ready-
to-go executable? Especially in some god-foresaken format like tar and
gz?

By the time you've put it all together, and you're very lucky, it /
might/ just work.

Because it's been 10 or 15 years since you last tried it?

Seriously, the huge majority of software distributed nowadays as source
uses the GNU autotools - type the three famous lines

./configure
make
make install

and It Just Works.
So goes the theory.

There's a fair amount of validity to Bart's position. Granted, it is
one of those things - it's free and it usually works. Whaddya want for
nothing? Things are much better with GNU autotools than they were in
the bad old days. Things are much better than that in the Windows
world, but, as we know, it doesn't always work in the Windows world either.

As a data point, I recently built DosBox from source. Everything went
fine - got all the pieces (SDL, etc) built with no error messages - and
the resulting executable "almost worked". The keyboard mapping was
wrong, and there was no way to fix it.

So, no, it doesn't always work.

Aug 31 '08 #21

P: n/a
"Malcolm McLean" <re*******@btinternet.comwrites:
[...]
The alternative to hardcode paths is softcoded paths. However Perl is
already an evolved shell script. The major thing that the shell does
is to allow the user to specify files by path. By demanding softcoded
paths in Perl you are taking away the natural facilities of the shell,
and creating a dependency.
On the other hand C is a compiled language. It is not possible to edit
the source and run, one must recompile. There might well be several
executables on different machines derived from the one C source. So
updating the C program when paths change is a major nuisance.

Basically, write everything that doesn't need hardcoded paths in C,
then write a Perl script to drive your C programs, with the paths
coded into the Perl script where it is too much of a burden on the
user to put them on the commandline.
You are mistaken on several points, one of which is your misuse of the
term "shell script". If you're interested in the details, feel free
to e-mail me. This whole thing is entirely off-topic here in
comp.lang.c.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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"
Aug 31 '08 #22

P: n/a
Keith Thompson <ks***@mib.orgwrites:
"Malcolm McLean" <re*******@btinternet.comwrites:
[...]
>The alternative to hardcode paths is softcoded paths. However Perl is
already an evolved shell script. The major thing that the shell does
is to allow the user to specify files by path. By demanding softcoded
paths in Perl you are taking away the natural facilities of the shell,
and creating a dependency.
On the other hand C is a compiled language. It is not possible to edit
the source and run, one must recompile. There might well be several
executables on different machines derived from the one C source. So
updating the C program when paths change is a major nuisance.

Basically, write everything that doesn't need hardcoded paths in C,
then write a Perl script to drive your C programs, with the paths
coded into the Perl script where it is too much of a burden on the
user to put them on the commandline.

You are mistaken on several points, one of which is your misuse of the
term "shell script". If you're interested in the details, feel free
to e-mail me. This whole thing is entirely off-topic here in
comp.lang.c.

It is perfectly on topic to discuss how one does things in C related to
other languages.
Aug 31 '08 #23

P: n/a
Bart wrote:
On Aug 31, 8:51 am, Richard Heathfield <r...@see.sig.invalidwrote:
>Andrew Poelstra said:
....
Why do I always get this sinking feeling whenever I need to download
something and it's only available as C sourcecode instead of a ready-
to-go executable? Especially in some god-foresaken format like tar and
gz?
I share your distaste for packages distributed as source code with
instructions on how to build it. However, I'm not too fond of
executables, either - most ready-to-go executables that I've seen aren't
"ready-to-go" on my machine. However, I've had very good results with
the packages I've installed that came in rpm format. However, if you
consider tar and gz as "god-forsaken", I suspect that you may have a
system where rpm won't do you much good, either.
Sep 1 '08 #24

P: n/a
In article <II******************************@bt.com>,
Malcolm McLean <re*******@btinternet.comwrote:
....
>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.
I think your choice of terminology may inflame some of the easily
enflamed members of this NG. I think what you are trying to say is that
the Perl language started out as an amalgam of shell and AWK (and
probably other things...) The similarity to shell is there, although
hard to see by some lights.

Sep 10 '08 #25

This discussion thread is closed

Replies have been disabled for this discussion.