Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.php > #3014 > unrolled thread
| Started by | jwcarlton <jwcarlton@gmail.com> |
|---|---|
| First post | 2011-08-30 17:23 -0700 |
| Last post | 2011-09-01 10:42 +0000 |
| Articles | 20 — 7 participants |
Back to article view | Back to comp.lang.php
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
| From | jwcarlton <jwcarlton@gmail.com> |
|---|---|
| Date | 2011-08-30 17:23 -0700 |
| Subject | PHP 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]
| From | "Peter H. Coffin" <hellsop@ninehells.com> |
|---|---|
| Date | 2011-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]
| From | jwcarlton <jwcarlton@gmail.com> |
|---|---|
| Date | 2011-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]
| From | "Peter H. Coffin" <hellsop@ninehells.com> |
|---|---|
| Date | 2011-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]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2011-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]
| From | "Álvaro G. Vicario" <alvaro.NOSPAMTHANX@demogracia.com.invalid> |
|---|---|
| Date | 2011-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]
| From | Goran <goran@nospam.com> |
|---|---|
| Date | 2011-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]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2011-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]
| From | jwcarlton <jwcarlton@gmail.com> |
|---|---|
| Date | 2011-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]
| From | "Peter H. Coffin" <hellsop@ninehells.com> |
|---|---|
| Date | 2011-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]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2011-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]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2011-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]
| From | "Álvaro G. Vicario" <alvaro.NOSPAMTHANX@demogracia.com.invalid> |
|---|---|
| Date | 2011-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]
| From | Luuk <Luuk@invalid.lan> |
|---|---|
| Date | 2011-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]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2011-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]
| From | Luuk <Luuk@invalid.lan> |
|---|---|
| Date | 2011-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]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2011-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]
| From | Luuk <Luuk@invalid.lan> |
|---|---|
| Date | 2011-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]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2011-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]
| From | Denis McMahon <denis.m.f.mcmahon@gmail.com> |
|---|---|
| Date | 2011-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