Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.php > #3014 > unrolled thread

PHP script to only be accessed by cron

Started byjwcarlton <jwcarlton@gmail.com>
First post2011-08-30 17:23 -0700
Last post2011-09-01 10:42 +0000
Articles 20 — 7 participants

Back to article view | Back to comp.lang.php


Contents

  PHP script to only be accessed by cron jwcarlton <jwcarlton@gmail.com> - 2011-08-30 17:23 -0700
    Re: PHP script to only be accessed by cron "Peter H. Coffin" <hellsop@ninehells.com> - 2011-08-30 19:44 -0500
      Re: PHP script to only be accessed by cron jwcarlton <jwcarlton@gmail.com> - 2011-08-30 19:16 -0700
        Re: PHP script to only be accessed by cron "Peter H. Coffin" <hellsop@ninehells.com> - 2011-08-31 07:15 -0500
          Re: PHP script to only be accessed by cron The Natural Philosopher <tnp@invalid.invalid> - 2011-08-31 17:48 +0100
    Re: PHP script to only be accessed by cron "Álvaro G. Vicario" <alvaro.NOSPAMTHANX@demogracia.com.invalid> - 2011-08-31 08:34 +0200
    Re: PHP script to only be accessed by cron Goran <goran@nospam.com> - 2011-08-31 08:43 +0200
    Re: PHP script to only be accessed by cron The Natural Philosopher <tnp@invalid.invalid> - 2011-08-31 09:20 +0100
      Re: PHP script to only be accessed by cron jwcarlton <jwcarlton@gmail.com> - 2011-08-31 02:14 -0700
        Re: PHP script to only be accessed by cron "Peter H. Coffin" <hellsop@ninehells.com> - 2011-08-31 07:53 -0500
          Re: PHP script to only be accessed by cron The Natural Philosopher <tnp@invalid.invalid> - 2011-08-31 17:58 +0100
        Re: PHP script to only be accessed by cron The Natural Philosopher <tnp@invalid.invalid> - 2011-08-31 17:45 +0100
        Re: PHP script to only be accessed by cron "Álvaro G. Vicario" <alvaro.NOSPAMTHANX@demogracia.com.invalid> - 2011-09-01 10:55 +0200
      Re: PHP script to only be accessed by cron Luuk <Luuk@invalid.lan> - 2011-08-31 20:37 +0200
        Re: PHP script to only be accessed by cron The Natural Philosopher <tnp@invalid.invalid> - 2011-08-31 20:49 +0100
          Re: PHP script to only be accessed by cron Luuk <Luuk@invalid.lan> - 2011-09-01 19:11 +0200
            Re: PHP script to only be accessed by cron The Natural Philosopher <tnp@invalid.invalid> - 2011-09-01 20:25 +0100
              Re: PHP script to only be accessed by cron Luuk <Luuk@invalid.lan> - 2011-09-01 21:45 +0200
                Re: PHP script to only be accessed by cron The Natural Philosopher <tnp@invalid.invalid> - 2011-09-02 00:30 +0100
    Re: PHP script to only be accessed by cron Denis McMahon <denis.m.f.mcmahon@gmail.com> - 2011-09-01 10:42 +0000

#3014 — PHP script to only be accessed by cron

Fromjwcarlton <jwcarlton@gmail.com>
Date2011-08-30 17:23 -0700
SubjectPHP script to only be accessed by cron
Message-ID<04759979-6bc8-4946-8a96-6e85775bc155@19g2000vbv.googlegroups.com>
I'm writing a PHP script that I want to ONLY be accessed by a
predefined cron. Can you guys suggest a way to prevent non-cron
accesses?

I wouldn't mind encoding the page, too, JUST in case I have a root
breach (not expected, of course, but not impossible). Since I would
only need to encode one page, once, would it be reasonable to use the
free trial of Zend Guard? Or would you guys suggest something
different?

TIA,

Jason

[toc] | [next] | [standalone]


#3015

From"Peter H. Coffin" <hellsop@ninehells.com>
Date2011-08-30 19:44 -0500
Message-ID<slrnj5r0v8.icc.hellsop@nibelheim.ninehells.com>
In reply to#3014
On Tue, 30 Aug 2011 17:23:06 -0700 (PDT), jwcarlton wrote:
> I'm writing a PHP script that I want to ONLY be accessed by a
> predefined cron. Can you guys suggest a way to prevent non-cron
> accesses?

No. But you can make it only accessable to the user who's ID is being
used to run the job by crond. See the documentation for the user
permissions for whatever OS is running thing. On unix-like systems, you
want to look at chmod(1). More detail than this isn't topical for a php
newsgroup, though.

> I wouldn't mind encoding the page, too, JUST in case I have a root
> breach (not expected, of course, but not impossible). Since I would
> only need to encode one page, once, would it be reasonable to use the
> free trial of Zend Guard? Or would you guys suggest something
> different?

Way, way, way too complicated. Stop thinking "page", start thinking
"script file".

-- 
72. If all the heroes are standing together around a strange device and
    begin to taunt me, I will pull out a conventional weapon instead of
    using my unstoppable superweapon on them.
	--Peter Anspach's list of things to do as an Evil Overlord

[toc] | [prev] | [next] | [standalone]


#3016

Fromjwcarlton <jwcarlton@gmail.com>
Date2011-08-30 19:16 -0700
Message-ID<19f7730e-74da-40fe-8f59-4ddd347bfa0f@q2g2000vbz.googlegroups.com>
In reply to#3015
> > I wouldn't mind encoding the page, too, JUST in case I have a root
> > breach (not expected, of course, but not impossible). Since I would
> > only need to encode one page, once, would it be reasonable to use the
> > free trial of Zend Guard? Or would you guys suggest something
> > different?
>
> Way, way, way too complicated. Stop thinking "page", start thinking
> "script file".

I'm not sure that I follow. If a hacker gains root access, I don't
want them to be able to go to the cron page and obtain the encryption
keys in the page; otherwise, they'll be able to get all of the
otherwise nicely secured data.

If not Zend Guard, what else do you recommend?

[toc] | [prev] | [next] | [standalone]


#3030

From"Peter H. Coffin" <hellsop@ninehells.com>
Date2011-08-31 07:15 -0500
Message-ID<slrnj5s9fd.icc.hellsop@nibelheim.ninehells.com>
In reply to#3016
On Tue, 30 Aug 2011 19:16:00 -0700 (PDT), jwcarlton wrote:
>> > I wouldn't mind encoding the page, too, JUST in case I have a root
>> > breach (not expected, of course, but not impossible). Since I would
>> > only need to encode one page, once, would it be reasonable to use the
>> > free trial of Zend Guard? Or would you guys suggest something
>> > different?
>>
>> Way, way, way too complicated. Stop thinking "page", start thinking
>> "script file".
>
> I'm not sure that I follow. If a hacker gains root access, I don't
> want them to be able to go to the cron page and obtain the encryption
> keys in the page; otherwise, they'll be able to get all of the
> otherwise nicely secured data.
>
> If not Zend Guard, what else do you recommend?

If an attacker gets root access, inside the system, the attacker has the
encryption keys, no matter where you bury them. Might as well make sure
that nobody can get them from *outside* the system, which you can
actually do something about.

-- 
When C++ is your hammer, everything looks like a thumb.
              -- Steven M. Haflich

[toc] | [prev] | [next] | [standalone]


#3035

FromThe Natural Philosopher <tnp@invalid.invalid>
Date2011-08-31 17:48 +0100
Message-ID<j3lol5$emr$2@news.albasani.net>
In reply to#3030
Peter H. Coffin wrote:
> On Tue, 30 Aug 2011 19:16:00 -0700 (PDT), jwcarlton wrote:
>>>> I wouldn't mind encoding the page, too, JUST in case I have a root
>>>> breach (not expected, of course, but not impossible). Since I would
>>>> only need to encode one page, once, would it be reasonable to use the
>>>> free trial of Zend Guard? Or would you guys suggest something
>>>> different?
>>> Way, way, way too complicated. Stop thinking "page", start thinking
>>> "script file".
>> I'm not sure that I follow. If a hacker gains root access, I don't
>> want them to be able to go to the cron page and obtain the encryption
>> keys in the page; otherwise, they'll be able to get all of the
>> otherwise nicely secured data.
>>
>> If not Zend Guard, what else do you recommend?
> 
> If an attacker gets root access, inside the system, the attacker has the
> encryption keys, no matter where you bury them. Might as well make sure
> that nobody can get them from *outside* the system, which you can
> actually do something about.
> 

well yes and no. If they are hard coded in a compiled program, at least 
without serious dissassembly they can only be used as that program 
intended, not generically.

In the similar way that reading /etc/passwd doesn't actually tell you 
want the password was, though it gives you a great chance of a brute 
force attack on it succeeding.

[toc] | [prev] | [next] | [standalone]


#3018

From"Álvaro G. Vicario" <alvaro.NOSPAMTHANX@demogracia.com.invalid>
Date2011-08-31 08:34 +0200
Message-ID<j3kklp$o6d$1@dont-email.me>
In reply to#3014
El 31/08/2011 2:23, jwcarlton escribió/wrote:
> I'm writing a PHP script that I want to ONLY be accessed by a
> predefined cron. Can you guys suggest a way to prevent non-cron
> accesses?
>
> I wouldn't mind encoding the page, too, JUST in case I have a root
> breach (not expected, of course, but not impossible). Since I would
> only need to encode one page, once, would it be reasonable to use the
> free trial of Zend Guard? Or would you guys suggest something
> different?

I'm sure you can get the process tree, find out whether the parent of 
your script's PID belongs to the cron binary and abort otherwise. 
However, the second paragraph talks about hackers and encoding, which 
gives the impression that non-cron execution is not the problem itself 
but you solution to some unmentioned problem.

I say so because it's pretty common that non-root users are allowed to 
schedule cron tasks and, of course, root is able to run any script on 
disc no matter the file permissions. Are those situations acceptable?

-- 
-- http://alvaro.es - Álvaro G. Vicario - Burgos, Spain
-- Mi sitio sobre programación web: http://borrame.com
-- Mi web de humor satinado: http://www.demogracia.com
--

[toc] | [prev] | [next] | [standalone]


#3020

FromGoran <goran@nospam.com>
Date2011-08-31 08:43 +0200
Message-ID<j3kl72$t2t$1@ss408.t-com.hr>
In reply to#3014
On 31.8.2011 2:23, jwcarlton wrote:
> I'm writing a PHP script that I want to ONLY be accessed by a
> predefined cron. Can you guys suggest a way to prevent non-cron
> accesses?

I guess your plan is to put that script inside a public directory. Thats
wrong... put it in some non-public directory end execute it via CLI
(from cron). That way it will be secured from non privileged users.

Forget about securing it from root user, it is not possible.

[toc] | [prev] | [next] | [standalone]


#3022

FromThe Natural Philosopher <tnp@invalid.invalid>
Date2011-08-31 09:20 +0100
Message-ID<j3kqst$flm$1@news.albasani.net>
In reply to#3014
jwcarlton wrote:
> I'm writing a PHP script that I want to ONLY be accessed by a
> predefined cron. Can you guys suggest a way to prevent non-cron
> accesses?
> 

1/. Write it in a proper language for this purpose, C, not php

2/. Check the id of the parent process: compare that with running 
processes . If it ain't cron abort the program.

3/. When you have it working, delete the source code.


> I wouldn't mind encoding the page, too, JUST in case I have a root
> breach (not expected, of course, but not impossible).


That's the second reason to write it in C.

Since I would
> only need to encode one page, once, would it be reasonable to use the
> free trial of Zend Guard? Or would you guys suggest something
> different?
> 

Why not start with the right approach, instead of patching the wrong 
approach?

I like PHP. But its not the only language in town and this is where I 
would definitely get out the C compiler

> TIA,
> 
> Jason

[toc] | [prev] | [next] | [standalone]


#3023

Fromjwcarlton <jwcarlton@gmail.com>
Date2011-08-31 02:14 -0700
Message-ID<a1203be2-09fc-4c66-a3bb-dcf9c2d59239@t3g2000vbe.googlegroups.com>
In reply to#3022
> > I'm writing a PHP script that I want to ONLY be accessed by a
> > predefined cron. Can you guys suggest a way to prevent non-cron
> > accesses?
>
> 1/. Write it in a proper language for this purpose, C, not php
>
> 2/. Check the id of the parent process: compare that with running
> processes . If it ain't cron abort the program.
>
> 3/. When you have it working, delete the source code.
>
> > I wouldn't mind encoding the page, too, JUST in case I have a root
> > breach (not expected, of course, but not impossible).
>
> That's the second reason to write it in C.
>
> Since I would
>
> > only need to encode one page, once, would it be reasonable to use the
> > free trial of Zend Guard? Or would you guys suggest something
> > different?
>
> Why not start with the right approach, instead of patching the wrong
> approach?
>
> I like PHP. But its not the only language in town and this is where I
> would definitely get out the C compiler

I think you make an excellent point, NP. It's been awhile since I've
messed with C and have forgotten more than I should, but I think
you're right that it's the appropriate language.

In retrospect, I don't know if I've EVER coded in C. I think I started
in C++. Oh, well, it's not a big deal to go find a compiler and see
what I remember :-)  "Hello World", here I come! LOL

FWIW, Alvaro, I don't really have a problem, I'm just trying to
prevent one before it has a chance to happen :-)  I figure that it's
better to tighten it up the best that I can in the beginning, instead
of trying to come back to it later. I'm more or less just playing with
this script right now, anyway.

[toc] | [prev] | [next] | [standalone]


#3031

From"Peter H. Coffin" <hellsop@ninehells.com>
Date2011-08-31 07:53 -0500
Message-ID<slrnj5sbmh.icc.hellsop@nibelheim.ninehells.com>
In reply to#3023
On Wed, 31 Aug 2011 02:14:58 -0700 (PDT), jwcarlton wrote:
>> > I'm writing a PHP script that I want to ONLY be accessed by a
>> > predefined cron. Can you guys suggest a way to prevent non-cron
>> > accesses?
>>
>> 1/. Write it in a proper language for this purpose, C, not php

Won't gain much relevant. Compilation isn't even obfuscation, much less
encryption. Run strings on a compiled c program sometime.

>> 2/. Check the id of the parent process: compare that with running
>> processes . If it ain't cron abort the program.

Marginal. Are you 100% sure, though, that cron will always spawn it
directly? On my host, it doesn't; cron spawns a process that sets up
the environment, which then spawns the actual command in the cron job
and accepts output for mailing back to the owning user, if any, then
exists itself.

----------------
#!/bin/ksh

echo "this process $$";
echo "parent process $PPID";
----------------

run by cron outputs

----------------
this process 20206
parent process 18169
----------------

while cron is pid 547:

$ ps aux | grep cron 
----------------
USER       PID %CPU %MEM   VSZ   RSS TT  STAT  STARTED       TIME COMMAND
----------------
root       547  0.0  0.0   632   868 ??  Is    22Jun11    0:13.07 cron

>> 3/. When you have it working, delete the source code.

So you can NEVER MAKE CHANGES AGAIN! (Okay, yes, you can keep a backup
elsewhere. Which makes it really easy to lose track of.)

>> > I wouldn't mind encoding the page, too, JUST in case I have a root
>> > breach (not expected, of course, but not impossible).
>>
>> That's the second reason to write it in C.
>>
>> Since I would
>>
>> > only need to encode one page, once, would it be reasonable to use the
>> > free trial of Zend Guard? Or would you guys suggest something
>> > different?
>>
>> Why not start with the right approach, instead of patching the wrong
>> approach?
>>
>> I like PHP. But its not the only language in town and this is where I
>> would definitely get out the C compiler
>
> I think you make an excellent point, NP. It's been awhile since I've
> messed with C and have forgotten more than I should, but I think
> you're right that it's the appropriate language.
>
> In retrospect, I don't know if I've EVER coded in C. I think I started
> in C++. Oh, well, it's not a big deal to go find a compiler and see
> what I remember :-)  "Hello World", here I come! LOL

Best of luck to you. I hope you have the time to build the skills
necessary for the job in the time you've got. (:

> FWIW, Alvaro, I don't really have a problem, I'm just trying to
> prevent one before it has a chance to happen :-)  I figure that it's
> better to tighten it up the best that I can in the beginning, instead
> of trying to come back to it later. I'm more or less just playing with
> this script right now, anyway.

Preventing problems is a good thing to do, but using the simplest method
to prevent the problem is the least likely to introduce other, shiny and
new problems that you haven't already thought of. Stick with simple:
secure the script written in a language you're already comfortable with
to a single user, have cron run it under that user id, be done with it.

-- 
When C++ is your hammer, everything looks like a thumb.
              -- Steven M. Haflich

[toc] | [prev] | [next] | [standalone]


#3036

FromThe Natural Philosopher <tnp@invalid.invalid>
Date2011-08-31 17:58 +0100
Message-ID<j3lp8g$ge2$1@news.albasani.net>
In reply to#3031
Peter H. Coffin wrote:
> On Wed, 31 Aug 2011 02:14:58 -0700 (PDT), jwcarlton wrote:
>>>> I'm writing a PHP script that I want to ONLY be accessed by a
>>>> predefined cron. Can you guys suggest a way to prevent non-cron
>>>> accesses?
>>> 1/. Write it in a proper language for this purpose, C, not php
> 
> Won't gain much relevant. Compilation isn't even obfuscation, much less
> encryption. Run strings on a compiled c program sometime.
> 
You miss the point completely: you want access to libaries about PIDS 
and PPIDS that are not within PHP directly. Sure you can use system ) or 
exec() calls, but since you probably need to write what amounts to an 
extension anyway why use PHP in the first place?

And only if you are relatively crass would you encode as a string. If 
you were worried about security.

There are many algorithms for generating strings and you would need to 
examine the machine code and determine which one has been used.

For instance a single character followed buy a sequence of numbers which 
have to be added sucessively to generate the lower 7 bits of an ascii 
message is very easy to organise.

i.e 'a',1,1,1,1,1,1

becomes abcdefg
strinsg isn't a deal of use there



>>> 2/. Check the id of the parent process: compare that with running
>>> processes . If it ain't cron abort the program.
> 
> Marginal. Are you 100% sure, though, that cron will always spawn it
> directly? On my host, it doesn't; cron spawns a process that sets up
> the environment, which then spawns the actual command in the cron job
> and accepts output for mailing back to the owning user, if any, then
> exists itself.
> 

recursively trace the PID and the PPID to see what the last level below 
init is.

> ----------------
> #!/bin/ksh
> 
> echo "this process $$";
> echo "parent process $PPID";
> ----------------
> 
> run by cron outputs
> 
> ----------------
> this process 20206
> parent process 18169
> ----------------
> 
> while cron is pid 547:

Thats cos its a shell script, not a c program,


> 
> $ ps aux | grep cron 
> ----------------
> USER       PID %CPU %MEM   VSZ   RSS TT  STAT  STARTED       TIME COMMAND
> ----------------
> root       547  0.0  0.0   632   868 ??  Is    22Jun11    0:13.07 cron
> 
>>> 3/. When you have it working, delete the source code.
> 
> So you can NEVER MAKE CHANGES AGAIN! (Okay, yes, you can keep a backup
> elsewhere. Which makes it really easy to lose track of.)
> 

That is the whole point. Doing things right is not for simple minded 
fools who cant count beyond ten without taking their pink booties off.


Have a compile and test environment and a different run time 
environment. And keep them separate.



>>>> I wouldn't mind encoding the page, too, JUST in case I have a root
>>>> breach (not expected, of course, but not impossible).
>>> That's the second reason to write it in C.
>>>
>>> Since I would
>>>
>>>> only need to encode one page, once, would it be reasonable to use the
>>>> free trial of Zend Guard? Or would you guys suggest something
>>>> different?
>>> Why not start with the right approach, instead of patching the wrong
>>> approach?
>>>
>>> I like PHP. But its not the only language in town and this is where I
>>> would definitely get out the C compiler
>> I think you make an excellent point, NP. It's been awhile since I've
>> messed with C and have forgotten more than I should, but I think
>> you're right that it's the appropriate language.
>>
>> In retrospect, I don't know if I've EVER coded in C. I think I started
>> in C++. Oh, well, it's not a big deal to go find a compiler and see
>> what I remember :-)  "Hello World", here I come! LOL
> 
> Best of luck to you. I hope you have the time to build the skills
> necessary for the job in the time you've got. (:
> 
>> FWIW, Alvaro, I don't really have a problem, I'm just trying to
>> prevent one before it has a chance to happen :-)  I figure that it's
>> better to tighten it up the best that I can in the beginning, instead
>> of trying to come back to it later. I'm more or less just playing with
>> this script right now, anyway.
> 
> Preventing problems is a good thing to do, but using the simplest method
> to prevent the problem is the least likely to introduce other, shiny and
> new problems that you haven't already thought of. Stick with simple:
> secure the script written in a language you're already comfortable with
> to a single user, have cron run it under that user id, be done with it.
> 

So says the carpenter who repaired the space shuttle with a six inch 
nail and a club hammer.

[toc] | [prev] | [next] | [standalone]


#3034

FromThe Natural Philosopher <tnp@invalid.invalid>
Date2011-08-31 17:45 +0100
Message-ID<j3lofi$emr$1@news.albasani.net>
In reply to#3023
jwcarlton wrote:
>>> I'm writing a PHP script that I want to ONLY be accessed by a
>>> predefined cron. Can you guys suggest a way to prevent non-cron
>>> accesses?
>> 1/. Write it in a proper language for this purpose, C, not php
>>
>> 2/. Check the id of the parent process: compare that with running
>> processes . If it ain't cron abort the program.
>>
>> 3/. When you have it working, delete the source code.
>>
>>> I wouldn't mind encoding the page, too, JUST in case I have a root
>>> breach (not expected, of course, but not impossible).
>> That's the second reason to write it in C.
>>
>> Since I would
>>
>>> only need to encode one page, once, would it be reasonable to use the
>>> free trial of Zend Guard? Or would you guys suggest something
>>> different?
>> Why not start with the right approach, instead of patching the wrong
>> approach?
>>
>> I like PHP. But its not the only language in town and this is where I
>> would definitely get out the C compiler
> 
> I think you make an excellent point, NP. It's been awhile since I've
> messed with C and have forgotten more than I should, but I think
> you're right that it's the appropriate language.
> 
> In retrospect, I don't know if I've EVER coded in C. I think I started
> in C++. Oh, well, it's not a big deal to go find a compiler and see
> what I remember :-)  "Hello World", here I come! LOL
> 
> FWIW, Alvaro, I don't really have a problem, I'm just trying to
> prevent one before it has a chance to happen :-)  I figure that it's
> better to tighten it up the best that I can in the beginning, instead
> of trying to come back to it later. I'm more or less just playing with
> this script right now, anyway.


I've been rediscovering C after a few years absence. And trying to 
write, if not understand C++. Which I always considered was just too 
smart for its own good, and not really needful for the sort of 
programming I wanted to do anyway.


I've still got a segfault to sort out in one cron program..sigh. It is 
fine when the remote web server has the data. Its fine if the remote 
webserver isn't there at all Or refuses the connection..

But I forgot that sometimes web servers can send data like 'sorry, the 
data you want is unavailable at this time'..THAT segfaults it..

[toc] | [prev] | [next] | [standalone]


#3047

From"Álvaro G. Vicario" <alvaro.NOSPAMTHANX@demogracia.com.invalid>
Date2011-09-01 10:55 +0200
Message-ID<j3nha9$8ib$1@dont-email.me>
In reply to#3023
El 31/08/2011 11:14, jwcarlton escribió/wrote:
> FWIW, Alvaro, I don't really have a problem, I'm just trying to
> prevent one before it has a chance to happen:-)   I figure that it's
> better to tighten it up the best that I can in the beginning, instead
> of trying to come back to it later. I'm more or less just playing with
> this script right now, anyway.

And we sill don't have the faintest clue about that the problem to fix 
can be.

It's alright, it's your task and your responsibility so you don't have 
to share it with the rest of the world. But please don't ask for advice 
in a public forum if you are not willing to disclose any detail. 
Questions on the line of «What hammer should I use with a 8x1" screw» 
can't get good answers by definition.


-- 
-- http://alvaro.es - Álvaro G. Vicario - Burgos, Spain
-- Mi sitio sobre programación web: http://borrame.com
-- Mi web de humor satinado: http://www.demogracia.com
--

[toc] | [prev] | [next] | [standalone]


#3038

FromLuuk <Luuk@invalid.lan>
Date2011-08-31 20:37 +0200
Message-ID<4e5e7f4e$0$2551$e4fe514c@news2.news.xs4all.nl>
In reply to#3022
On 31-08-2011 10:20, The Natural Philosopher wrote:
> jwcarlton wrote:
>> I'm writing a PHP script that I want to ONLY be accessed by a
>> predefined cron. Can you guys suggest a way to prevent non-cron
>> accesses?
>>
> 
> 1/. Write it in a proper language for this purpose, C, not php


The purpose of this script is not give, at least not by the OP.
Can you tell here why PHP would not be the 'proper language'?

PHP can be used form the comman line quit well, see:
http://www.php.net/manual/en/features.commandline.interactive.php
for some examples

There's NO need to learn how to program in C, if one can do this task in PHP

-- 
Luuk

[toc] | [prev] | [next] | [standalone]


#3039

FromThe Natural Philosopher <tnp@invalid.invalid>
Date2011-08-31 20:49 +0100
Message-ID<j3m388$86o$1@news.albasani.net>
In reply to#3038
Luuk wrote:
> On 31-08-2011 10:20, The Natural Philosopher wrote:
>> jwcarlton wrote:
>>> I'm writing a PHP script that I want to ONLY be accessed by a
>>> predefined cron. Can you guys suggest a way to prevent non-cron
>>> accesses?
>>>
>> 1/. Write it in a proper language for this purpose, C, not php
> 
> 
> The purpose of this script is not give, at least not by the OP.
> Can you tell here why PHP would not be the 'proper language'?
> 

the main thinking Luuk was that to do what he wanted would invove a lot 
of calls to libraries that are not a standard part of PHP but are a part 
of the C library


Although I stand corrected because get_ppid() does seem to exist in PHP, 
and that's half the battle.


I cant remember the way to programmatically read a process table as ps 
does, but I am fairly sure php doesn't have a function to do it.



> PHP can be used form the comman line quit well, see:
> http://www.php.net/manual/en/features.commandline.interactive.php
> for some examples
> 
> There's NO need to learn how to program in C, if one can do this task in PHP
> 

Well firstly if you can code PHP its not a huge step to C, especially if 
you have some crib code.

secondly its a shade more secure if you hide passwords and so on inside 
nmunged data.

But my real reason was access to system libaries that dont as a rule 
come with PHP.

Libproc.a is the standard way I believe  to examine the /proc filesystem 
where all this info exists.

In the end its a tradeoff between writing something in PHP to 
interrogate that, and using some pre-existent source code in C

I've had similar issues with certain things where PHP did not handle 
concurrent accesses to certain graphics libraries well. Very strange 
bugs happened. Re wrote it in C and no more problems as I used a 
different graphics library that PHP did not support.

I am a great fan of PHP but there are times when I abandon it because - 
mainly - I need a library it doesn't support.

And I have not yet tackled the issues of writing my own extensions to it.

And although I know you can, I'd rather use shell or C for cron scripts. 
PHP can be used, but for me its strengths lie in its easy merging with 
HTML and mySQL: Althouh even there, I have written database interfaces 
in C easily enough. C just doesn't do outputting of straight HTML the 
way a ?> does ! :-)

I suppose at the end of the day is no big deal to write a massive 
printf() statement, but is more tedious than a ?>



[toc] | [prev] | [next] | [standalone]


#3050

FromLuuk <Luuk@invalid.lan>
Date2011-09-01 19:11 +0200
Message-ID<4e5fbcb7$0$2490$e4fe514c@news2.news.xs4all.nl>
In reply to#3039
On 31-08-2011 21:49, The Natural Philosopher wrote:
> Luuk wrote:
>> On 31-08-2011 10:20, The Natural Philosopher wrote:
>>> jwcarlton wrote:
>>>> I'm writing a PHP script that I want to ONLY be accessed by a
>>>> predefined cron. Can you guys suggest a way to prevent non-cron
>>>> accesses?
>>>>
>>> 1/. Write it in a proper language for this purpose, C, not php
>>
>>
>> The purpose of this script is not give, at least not by the OP.
>> Can you tell here why PHP would not be the 'proper language'?
>>
> 
> the main thinking Luuk was that to do what he wanted would invove a lot
> of calls to libraries that are not a standard part of PHP but are a part
> of the C library
> 


i dont see this part:
"to do what he wanted would invove a lot of calls to libraries"

but it can be caused by my lack of understanding English.... ;)

-- 
Luuk

[toc] | [prev] | [next] | [standalone]


#3051

FromThe Natural Philosopher <tnp@invalid.invalid>
Date2011-09-01 20:25 +0100
Message-ID<j3om6c$bjp$2@news.albasani.net>
In reply to#3050
Luuk wrote:
> On 31-08-2011 21:49, The Natural Philosopher wrote:
>> Luuk wrote:
>>> On 31-08-2011 10:20, The Natural Philosopher wrote:
>>>> jwcarlton wrote:
>>>>> I'm writing a PHP script that I want to ONLY be accessed by a
>>>>> predefined cron. Can you guys suggest a way to prevent non-cron
>>>>> accesses?
>>>>>
>>>> 1/. Write it in a proper language for this purpose, C, not php
>>>
>>> The purpose of this script is not give, at least not by the OP.
>>> Can you tell here why PHP would not be the 'proper language'?
>>>
>> the main thinking Luuk was that to do what he wanted would invove a lot
>> of calls to libraries that are not a standard part of PHP but are a part
>> of the C library
>>
> 
> 
> i dont see this part:
> "to do what he wanted would invove a lot of calls to libraries"
> 
> but it can be caused by my lack of understanding English.... ;)
> 
Or ..programming languages...and computer software architecture..

[toc] | [prev] | [next] | [standalone]


#3052

FromLuuk <Luuk@invalid.lan>
Date2011-09-01 21:45 +0200
Message-ID<4e5fe0d7$0$2493$e4fe514c@news2.news.xs4all.nl>
In reply to#3051
On 01-09-2011 21:25, The Natural Philosopher wrote:
> Luuk wrote:
>> On 31-08-2011 21:49, The Natural Philosopher wrote:
>>> Luuk wrote:
>>>> On 31-08-2011 10:20, The Natural Philosopher wrote:
>>>>> jwcarlton wrote:
>>>>>> I'm writing a PHP script that I want to ONLY be accessed by a
>>>>>> predefined cron. Can you guys suggest a way to prevent non-cron
>>>>>> accesses?
>>>>>>
>>>>> 1/. Write it in a proper language for this purpose, C, not php
>>>>
>>>> The purpose of this script is not give, at least not by the OP.
>>>> Can you tell here why PHP would not be the 'proper language'?
>>>>
>>> the main thinking Luuk was that to do what he wanted would invove a lot
>>> of calls to libraries that are not a standard part of PHP but are a part
>>> of the C library
>>>
>>
>>
>> i dont see this part:
>> "to do what he wanted would invove a lot of calls to libraries"
>>
>> but it can be caused by my lack of understanding English.... ;)
>>
> Or ..programming languages...and computer software architecture..
> 

sorry,
i still dont get what the OP's question has to do with 'a loc of calls
to libraries'

I know enough about programming languages and/or computer software
architecture ..... (enough=enough)

-- 
Luuk

[toc] | [prev] | [next] | [standalone]


#3054

FromThe Natural Philosopher <tnp@invalid.invalid>
Date2011-09-02 00:30 +0100
Message-ID<j3p4j9$d5e$1@news.albasani.net>
In reply to#3052
Luuk wrote:
> On 01-09-2011 21:25, The Natural Philosopher wrote:
>> Luuk wrote:
>>> On 31-08-2011 21:49, The Natural Philosopher wrote:
>>>> Luuk wrote:
>>>>> On 31-08-2011 10:20, The Natural Philosopher wrote:
>>>>>> jwcarlton wrote:
>>>>>>> I'm writing a PHP script that I want to ONLY be accessed by a
>>>>>>> predefined cron. Can you guys suggest a way to prevent non-cron
>>>>>>> accesses?
>>>>>>>
>>>>>> 1/. Write it in a proper language for this purpose, C, not php
>>>>> The purpose of this script is not give, at least not by the OP.
>>>>> Can you tell here why PHP would not be the 'proper language'?
>>>>>
>>>> the main thinking Luuk was that to do what he wanted would invove a lot
>>>> of calls to libraries that are not a standard part of PHP but are a part
>>>> of the C library
>>>>
>>>
>>> i dont see this part:
>>> "to do what he wanted would invove a lot of calls to libraries"
>>>
>>> but it can be caused by my lack of understanding English.... ;)
>>>
>> Or ..programming languages...and computer software architecture..
>>
> 
> sorry,
> i still dont get what the OP's question has to do with 'a loc of calls
> to libraries'
> 
> I know enough about programming languages and/or computer software
> architecture ..... (enough=enough)
> 
The solution involves accessing the process list.

There are less tools in PHP libraries than in C ones.

[toc] | [prev] | [next] | [standalone]


#3048

FromDenis McMahon <denis.m.f.mcmahon@gmail.com>
Date2011-09-01 10:42 +0000
Message-ID<4e5f6193$0$2946$a8266bb1@newsreader.readnews.com>
In reply to#3014
On Tue, 30 Aug 2011 17:23:06 -0700, jwcarlton wrote:

> I'm writing a PHP script that I want to ONLY be accessed by a predefined
> cron. Can you guys suggest a way to prevent non-cron accesses?
> 
> I wouldn't mind encoding the page, too, JUST in case I have a root
> breach (not expected, of course, but not impossible). Since I would only
> need to encode one page, once, would it be reasonable to use the free
> trial of Zend Guard? Or would you guys suggest something different?

You can't prevent non cron access, because root can do anything.

You could create a special user account that was prevented from 
interactive login, make your script only readable by this user, and 
execute the cron job as this user.

That's probably the best you can do unless you also encrypt the hard 
drives.

First of all, you need to assess how much security you actually want / 
need. If you really want your data to be secure, then you need to put the 
computer in a faraday caged vault with no external data lines and 
filtered power supplies.

Then you only need to worry about the integrity of the people who have 
access to the vault.

Rgds

Denis McMahon

[toc] | [prev] | [standalone]


Back to top | Article view | comp.lang.php


csiph-web