🚀 go-pugleaf

Vincent Spruyt wrote:
> Heb momenteel eigenlijk geen tijd om php te leren, en ik probeer dus mijn 
> codes te maken adhv wat voorbeelden en broncodes.
> Nu heb ik een vraagje...
> Ik maakte een code die
> 
> 1) een deel broncode van pine.nl leest (met toestemming), een aantal 
> dingen vervangt en filtert, en het geheel in een VAR $code zet.
> 2) $code wordt ge-echo't, en wordt opgeslagen in een bestand pine.cache
> 3) het uur waarop dit gebeurt (bvb 4) wordt opgeslagen in update.cache. 
> Als update.cache bestaat, bestaat pine.cache dus ook, en omgekeerd.
> 
> Nu is het de bedoeling dat de gegevens gegrabd worden van pine.nl, maar 
> dit enkel als ze ouder zijn dan 1 u.
> maw, 
<knip veel te lange post>

Als je "cron" kan gebruiken dan kan je om het uur die pagina fetchen &
verwerken. Kan je dit niet - omdat je geen login op je webserver bv. -
dan kan je gebruik maken van de cache mogelijkheden in php.

zie: 

http://www.linuxjournal.com/article.php?sid=5661 ( ge zult toch iets
moeten lezen :) )

> Kan ik dat stuk code dan niet in een of andere functie of variabele 
> ofzoiets steken en dan oproepen.
> hoe gaat dat?

zoek op http://www.php.net naar function.

-- 
Staf Wagemakers

email:          staf@patat.org
homepage:       http://staf.patat.org

Vincent Spruyt schreef:

> 1) een deel broncode van pine.nl leest (met toestemming), een
> aantal dingen vervangt en filtert, en het geheel in een VAR $code
> zet. 2) $code wordt ge-echo't, en wordt opgeslagen in een bestand
> pine.cache 3) het uur waarop dit gebeurt (bvb 4) wordt opgeslagen
> in update.cache. Als update.cache bestaat, bestaat pine.cache dus
> ook, en omgekeerd. 

Waarom met 2 files gaan werken waarvan de 2de dan ook nog nutteloos is? 

Vraag gewoon de last-modified-tijd op van je pine.cache geval op en 
vergelijk die met de huidige tijd.


Jeffrey
-- 
.: PEBBELS : het klikt tussen ons :.
: www.pebbels.be .. irc.pebbels.be :

staf wagemakers <stafwag@yahoo.com> schreef in
news:slrnaoub4c.8n4.stafwag@staflaptop.antw.the-ecorp.com: 

> Vincent Spruyt wrote:
>> Heb momenteel eigenlijk geen tijd om php te leren, en ik probeer dus
>> mijn codes te maken adhv wat voorbeelden en broncodes.
>> Nu heb ik een vraagje...
>> Ik maakte een code die
>> 
>> 1) een deel broncode van pine.nl leest (met toestemming), een aantal 
>> dingen vervangt en filtert, en het geheel in een VAR $code zet.
>> 2) $code wordt ge-echo't, en wordt opgeslagen in een bestand
>> pine.cache 3) het uur waarop dit gebeurt (bvb 4) wordt opgeslagen in
>> update.cache. Als update.cache bestaat, bestaat pine.cache dus ook,
>> en omgekeerd. 
>> 
>> Nu is het de bedoeling dat de gegevens gegrabd worden van pine.nl,
>> maar dit enkel als ze ouder zijn dan 1 u.
>> maw, 
> <knip veel te lange post>
> 
> Als je "cron" kan gebruiken dan kan je om het uur die pagina fetchen &
> verwerken. Kan je dit niet - omdat je geen login op je webserver bv. -
> dan kan je gebruik maken van de cache mogelijkheden in php.
> 
> zie: 
> 
> http://www.linuxjournal.com/article.php?sid=5661 ( ge zult toch iets
> moeten lezen :) )

lukt me niet meteen, maar toch bedankt. Was interessante lectuur ;-)
 
>> Kan ik dat stuk code dan niet in een of andere functie of variabele 
>> ofzoiets steken en dan oproepen.
>> hoe gaat dat?
> 
> zoek op http://www.php.net naar function.

Dacht al zoiets. thx! Ga ik zeker kunnen gebruiken.

-- 
Computer games don't affect kids; I mean if Pac-Man affected us as kids, 
we'd all be running around in darkened rooms, munching magic pills and 
listening to repetitive electronic music. (Christian Wilson)
		- <url:http://www.computersecurity.be/> -

Jeffrey Drooghenbroodt <jeffrey@pebbels.be> schreef in 
news:Xns9292B5F9EBA57IIjeffrey@pebbels.be:

> Vincent Spruyt schreef:
> 
>> 1) een deel broncode van pine.nl leest (met toestemming), een
>> aantal dingen vervangt en filtert, en het geheel in een VAR $code
>> zet. 2) $code wordt ge-echo't, en wordt opgeslagen in een bestand
>> pine.cache 3) het uur waarop dit gebeurt (bvb 4) wordt opgeslagen
>> in update.cache. Als update.cache bestaat, bestaat pine.cache dus
>> ook, en omgekeerd. 
> 
> Waarom met 2 files gaan werken waarvan de 2de dan ook nog nutteloos is? 
> 
> Vraag gewoon de last-modified-tijd op van je pine.cache geval op en 
> vergelijk die met de huidige tijd.

you're right, thx!

$filemod = filemtime("pine.cache");
$filemodtime = date("g", $filemod);

Geeft hetzelfde als wat ik in de update.cache plaatste, maar zo moet ik 
geen 2de bestand laten aanmaken. thx a lot.
Nu nog zien uit te vissen hoe mij if-else structuur juist moet ;-) Zal 
wel lukken denk ik.

-- 
Computer games don't affect kids; I mean if Pac-Man affected us as kids, 
we'd all be running around in darkened rooms, munching magic pills and 
listening to repetitive electronic music. (Christian Wilson)
		- <url:http://www.computersecurity.be/> -

staf wagemakers <stafwag@yahoo.com> schreef in
news:slrnaoub4c.8n4.stafwag@staflaptop.antw.the-ecorp.com: 

> Vincent Spruyt wrote:
>> Heb momenteel eigenlijk geen tijd om php te leren, en ik probeer dus
>> mijn codes te maken adhv wat voorbeelden en broncodes.
>> Nu heb ik een vraagje...
>> Ik maakte een code die
>> 
>> 1) een deel broncode van pine.nl leest (met toestemming), een aantal 
>> dingen vervangt en filtert, en het geheel in een VAR $code zet.
>> 2) $code wordt ge-echo't, en wordt opgeslagen in een bestand
>> pine.cache 3) het uur waarop dit gebeurt (bvb 4) wordt opgeslagen in
>> update.cache. Als update.cache bestaat, bestaat pine.cache dus ook,
>> en omgekeerd. 
>> 
>> Nu is het de bedoeling dat de gegevens gegrabd worden van pine.nl,
>> maar dit enkel als ze ouder zijn dan 1 u.
>> maw, 
> <knip veel te lange post>
> 
> Als je "cron" kan gebruiken dan kan je om het uur die pagina fetchen &
> verwerken. Kan je dit niet - omdat je geen login op je webserver bv. -
> dan kan je gebruik maken van de cache mogelijkheden in php.
> 
> zie: 
> 
> http://www.linuxjournal.com/article.php?sid=5661 ( ge zult toch iets
> moeten lezen :) )
> 
>> Kan ik dat stuk code dan niet in een of andere functie of variabele 
>> ofzoiets steken en dan oproepen.
>> hoe gaat dat?
> 
> zoek op http://www.php.net naar function.

hmm, een functie maak je blijkbaar op deze manier:
$newfunc = create_function('$a,$b','return "ln($a) + ln($b) = ".log($a * 
$b);');

Nu is het probleem dat je die ' moet zetten...
De code die ik in die var zou willen zetten is nogal vrij uitgebreid, en 
er worden zowel single als double quotes gebruikt...

$functie = create_function ('
hier heel mijn code met zowel " als '
')
werkt dus niet...
Verder wel iets interessant die function... kan ik volgens mij het aantal 
regels code van mijn menu mee halveren... hoewel.. delen door 15 ofzo ;-)

-- 
Computer games don't affect kids; I mean if Pac-Man affected us as kids, 
we'd all be running around in darkened rooms, munching magic pills and 
listening to repetitive electronic music. (Christian Wilson)
		- <url:http://www.computersecurity.be/> -

Vincent Spruyt <info@computersecurity.be> wrote:
> Verder wel iets interessant die function... kan ik volgens mij het aantal 
> regels code van mijn menu mee halveren... hoewel.. delen door 15 ofzo ;-)

Ooit leren programmeren?

function foo() {
	echo "Dit is toch wel geen lijntje output zekers?\n";
}

foo();
echo "en nu iets anders\n\n";
foo();
foo();
foo();

Vriendelijke groeten,
Frank Louwers

-- 
Openminds bvba                www.openminds.be
Tweebruggenstraat 16  -  9000 Gent  -  Belgium

Vincent Spruyt writes:

> hmm, een functie maak je blijkbaar op deze manier: $newfunc =
> create_function('$a,$b','return "ln($a) + ln($b) = ".log($a *
> $b);');

nee, een functie maak je zo:

function foo() {
 // doe iets...
}

die create_function van jou is iets veel ingewikkelders, dat dient om
"lambda" ( dwz. naamloze ) functies te creeren.  ( nu ja, ze zijn niet
echt naamloos, maar krijgen een willekeurige naam, die je in een
variabele moet opslaan, wat dus op hetzelfde neerkomt als "de functie
zelf opslaan" )
sjuus
domi

-- 
Today's weirdness is tomorrow's reason why.
		-- Hunter S. Thompson

frank@openminds.be schreef in
news:amnse0$7hp47$1@ID-103399.news.dfncis.de: 

> Vincent Spruyt <info@computersecurity.be> wrote:
>> Verder wel iets interessant die function... kan ik volgens mij het
>> aantal regels code van mijn menu mee halveren... hoewel.. delen door
>> 15 ofzo ;-) 
> 
> Ooit leren programmeren?

nope

> 
> function foo() {
>      echo "Dit is toch wel geen lijntje output zekers?\n";
> }
> 
> foo();
> echo "en nu iets anders\n\n";
> foo();
> foo();
> foo();

hmm, ben ook even met die function iets()bezig geweest, maar dacht dat 
dat diende om een reeds gemaakte functie op te roepen.
Bedankt!

-- 
Computer games don't affect kids; I mean if Pac-Man affected us as kids, 
we'd all be running around in darkened rooms, munching magic pills and 
listening to repetitive electronic music. (Christian Wilson)
		- <url:http://www.computersecurity.be/> -

Dominique Devriese <dominique.devriese@student.kuleuven.ac.be> schreef in 
news:87it0wpis7.fsf@appel.kotnet.org:

> Vincent Spruyt writes:
> 
>> hmm, een functie maak je blijkbaar op deze manier: $newfunc =
>> create_function('$a,$b','return "ln($a) + ln($b) = ".log($a *
>> $b);');
> 
> nee, een functie maak je zo:
> 
> function foo() {
>  // doe iets...
> }
> 
> die create_function van jou is iets veel ingewikkelders, dat dient om
> "lambda" ( dwz. naamloze ) functies te creeren.  ( nu ja, ze zijn niet
> echt naamloos, maar krijgen een willekeurige naam, die je in een
> variabele moet opslaan, wat dus op hetzelfde neerkomt als "de functie
> zelf opslaan" )

thx!


-- 
Computer games don't affect kids; I mean if Pac-Man affected us as kids, 
we'd all be running around in darkened rooms, munching magic pills and 
listening to repetitive electronic music. (Christian Wilson)
		- <url:http://www.computersecurity.be/> -

Vincent Spruyt schreef:

> $filemod = filemtime("pine.cache");
> $filemodtime = date("g", $filemod);
> 
> Geeft hetzelfde als wat ik in de update.cache plaatste, maar zo
> moet ik geen 2de bestand laten aanmaken. thx a lot.
> Nu nog zien uit te vissen hoe mij if-else structuur juist moet ;-)
> Zal wel lukken denk ik.

Gewoon je $filemod vergelijken met $tijd - 1u... 

Is het resultaat positief, dan toon je de cache; is het negatief, dan 
ga je eerst je cache updaten.


Jeffrey
-- 
.: PEBBELS : het klikt tussen ons :.
: www.pebbels.be .. irc.pebbels.be :

Jeffrey Drooghenbroodt <jeffrey@pebbels.be> schreef in 
news:Xns92935B19CD08DIIjeffrey@pebbels.be:

> Vincent Spruyt schreef:
> 
>> $filemod = filemtime("pine.cache");
>> $filemodtime = date("g", $filemod);
>> 
>> Geeft hetzelfde als wat ik in de update.cache plaatste, maar zo
>> moet ik geen 2de bestand laten aanmaken. thx a lot.
>> Nu nog zien uit te vissen hoe mij if-else structuur juist moet ;-)
>> Zal wel lukken denk ik.
> 
> Gewoon je $filemod vergelijken met $tijd - 1u... 
> 
> Is het resultaat positief, dan toon je de cache; is het negatief, dan 

yupz, behalve als de cache updated is om 12u, en $tijd = 1u


-- 
Computer games don't affect kids; I mean if Pac-Man affected us as kids, 
we'd all be running around in darkened rooms, munching magic pills and 
listening to repetitive electronic music. (Christian Wilson)
		- <url:http://www.computersecurity.be/> -

Vincent Spruyt wrote:

> Jeffrey Drooghenbroodt <jeffrey@pebbels.be> schreef in
> news:Xns92935B19CD08DIIjeffrey@pebbels.be:
> 
>> Vincent Spruyt schreef:
>> 
>>> $filemod = filemtime("pine.cache");
>>> $filemodtime = date("g", $filemod);
>>> 
>>> Geeft hetzelfde als wat ik in de update.cache plaatste, maar zo
>>> moet ik geen 2de bestand laten aanmaken. thx a lot.
>>> Nu nog zien uit te vissen hoe mij if-else structuur juist moet ;-)
>>> Zal wel lukken denk ik.
>> 
>> Gewoon je $filemod vergelijken met $tijd - 1u...
>> 
>> Is het resultaat positief, dan toon je de cache; is het negatief, dan
> 
> yupz, behalve als de cache updated is om 12u, en $tijd = 1u
> 
> 

zet dat terug naar een unixtimestamp ....

Hans

Hans Zimmerman <hansMAPSON@everlasting.be.invalid> schreef in 
news:5RXj9.130182$8o4.19313@afrodite.telenet-ops.be:

> Vincent Spruyt wrote:
> 
>> Jeffrey Drooghenbroodt <jeffrey@pebbels.be> schreef in
>> news:Xns92935B19CD08DIIjeffrey@pebbels.be:
>> 
>>> Vincent Spruyt schreef:
>>> 
>>>> $filemod = filemtime("pine.cache");
>>>> $filemodtime = date("g", $filemod);
>>>> 
>>>> Geeft hetzelfde als wat ik in de update.cache plaatste, maar zo
>>>> moet ik geen 2de bestand laten aanmaken. thx a lot.
>>>> Nu nog zien uit te vissen hoe mij if-else structuur juist moet ;-)
>>>> Zal wel lukken denk ik.
>>> 
>>> Gewoon je $filemod vergelijken met $tijd - 1u...
>>> 
>>> Is het resultaat positief, dan toon je de cache; is het negatief, dan
>> 
>> yupz, behalve als de cache updated is om 12u, en $tijd = 1u
>> 
>> 
> 
> zet dat terug naar een unixtimestamp ....

met time() kan ik de unixtimestamp van dit moment wel opvragen, maar die 
van het moment dat mijn file geupdate werd krijg ik niet terug.

-- 
Computer games don't affect kids; I mean if Pac-Man affected us as kids, 
we'd all be running around in darkened rooms, munching magic pills and 
listening to repetitive electronic music. (Christian Wilson)
		- <url:http://www.computersecurity.be/> -

Vincent Spruyt <info@computersecurity.be> schreef in 
news:Xns92938B0756F97www.computersecurity@195.130.132.65:

> $filemod = filemtime("pine.cache");

of toch! bedankt!

-- 
Computer games don't affect kids; I mean if Pac-Man affected us as kids, 
we'd all be running around in darkened rooms, munching magic pills and 
listening to repetitive electronic music. (Christian Wilson)
		- <url:http://www.computersecurity.be/> -

Vincent Spruyt <info@computersecurity.be> schreef in 
news:Xns92938B579C43Ewww.computersecurity@195.130.132.65:

> Vincent Spruyt <info@computersecurity.be> schreef in 
> news:Xns92938B0756F97www.computersecurity@195.130.132.65:
> 
>> $filemod = filemtime("pine.cache");
> 
> of toch! bedankt!

Ik ben er eindelijk geraakt! ;-) Thx a lot allemaal. Heb veel bijgeleerd, 
en ik ga binnekort toch maar eens die php leren ;-) Best handig.

script in actie: http://www.computersecurity.be/test/pine.php
bron: http://www.computersecurity.be/test/pine.phps

-- 
Computer games don't affect kids; I mean if Pac-Man affected us as kids, 
we'd all be running around in darkened rooms, munching magic pills and 
listening to repetitive electronic music. (Christian Wilson)
		- <url:http://www.computersecurity.be/> -

Vincent Spruyt <info@computersecurity.be> schreef in
news:Xns92938F9FD9264www.computersecurity@195.130.132.65: 

> Vincent Spruyt <info@computersecurity.be> schreef in 
> news:Xns92938B579C43Ewww.computersecurity@195.130.132.65:
> 
>> Vincent Spruyt <info@computersecurity.be> schreef in 
>> news:Xns92938B0756F97www.computersecurity@195.130.132.65:
>> 
>>> $filemod = filemtime("pine.cache");
>> 
>> of toch! bedankt!
> 
> Ik ben er eindelijk geraakt! ;-) Thx a lot allemaal. Heb veel
> bijgeleerd, en ik ga binnekort toch maar eens die php leren ;-) Best
> handig. 
> 
> script in actie: http://www.computersecurity.be/test/pine.php
> bron: http://www.computersecurity.be/test/pine.phps

sorry dat ik zo tegen mezelf praat ;-)
Maar wat ik wel nog vreemd vind, is, dat de chmod van pine.cache op 720 
staat, en toch kan iedereen het nog lezen...

-- 
Computer games don't affect kids; I mean if Pac-Man affected us as kids, 
we'd all be running around in darkened rooms, munching magic pills and 
listening to repetitive electronic music. (Christian Wilson)
		- <url:http://www.computersecurity.be/> -

On Tue, 24 Sep 2002 12:13:02 GMT, Vincent Spruyt <info@computersecurity.be>
wrote:
>  sorry dat ik zo tegen mezelf praat ;-)
>  Maar wat ik wel nog vreemd vind, is, dat de chmod van pine.cache op 720 
>  staat, en toch kan iedereen het nog lezen...

Misschien (hoogstwaarschijnlijk) dat Apache als UID deze van de eigenaar van
pine.cache heeft (of root, dat kan ook).

Mvg,
	Sven Vermeulen  

Sven Vermeulen <svenPUNTJEvermeulen@rug.ac.be> schreef in
news:%OYj9.130211$8o4.19177@afrodite.telenet-ops.be: 

> On Tue, 24 Sep 2002 12:13:02 GMT, Vincent Spruyt
> <info@computersecurity.be> wrote:
>>  sorry dat ik zo tegen mezelf praat ;-)
>>  Maar wat ik wel nog vreemd vind, is, dat de chmod van pine.cache op
>>  720 staat, en toch kan iedereen het nog lezen...
> 
> Misschien (hoogstwaarschijnlijk) dat Apache als UID deze van de
> eigenaar van pine.cache heeft (of root, dat kan ook).

Wat je hier bedoeld begrijp ik niet echt, maar veilig klinkt het niet ;-)

-- 
Computer games don't affect kids; I mean if Pac-Man affected us as kids, 
we'd all be running around in darkened rooms, munching magic pills and 
listening to repetitive electronic music. (Christian Wilson)
		- <url:http://www.computersecurity.be/> -

Vincent Spruyt writes:

> Sven Vermeulen <svenPUNTJEvermeulen@rug.ac.be> schreef in
> news:%OYj9.130211$8o4.19177@afrodite.telenet-ops.be:

>> On Tue, 24 Sep 2002 12:13:02 GMT, Vincent Spruyt
>> <info@computersecurity.be> wrote:
>>> sorry dat ik zo tegen mezelf praat ;-) Maar wat ik wel nog vreemd
>>> vind, is, dat de chmod van pine.cache op 720 staat, en toch kan
>>> iedereen het nog lezen...
>>
>> Misschien (hoogstwaarschijnlijk) dat Apache als UID deze van de
>> eigenaar van pine.cache heeft (of root, dat kan ook).

> Wat je hier bedoeld begrijp ik niet echt, maar veilig klinkt het
> niet ;-)

UNIX toegangscontrole bepaalt welke UNIX "user" toegang heeft tot een
bepaald bestand.  Elk programma draait als een bepaalde user.  Als jij
inlogt, dan draait je shell als de user waarmee je inlogt.  Apache
draait ook als een bepaalde user.  Over het algemeen heet deze httpd
of apache of zo, maar het kan zijn ( als je sysadmin zijn vak niet
kent ) dat deze als root draait.
De file-permissies 720 bepalen dat de eigenaar van het bestand het
bestand mag uitvoeren ( ?? ), lezen en schrijven, en dat de groep
waarvan het eigendom is, het bestand mag schrijven ( ?? ), maar niet
lezen en uitvoeren.  Users die niet tot die groep behoren mogen niets
doen met het bestand.
Waarschijnlijk is het bestand in kwestie eigendom van de user apache
of httpd, ofwel draai je apache als root.  Dat laatste zou erg dom
zijn, maar je permissies staan ook vrij raar, dus misschien heb je er
wel wat mee zitten knoeien ?
sjuus
domi

-- 
The difference between a Miracle and a Fact is exactly the difference
between a mermaid and a seal.
		-- Mark Twain

On Tue, 24 Sep 2002 12:27:32 GMT, Vincent Spruyt <info@computersecurity.be>
wrote:
[... file perms 720, iedereen kan ze leven via internet ...]
>  Wat je hier bedoeld begrijp ik niet echt, maar veilig klinkt het niet ;-)

Je file heeft een bepaalde eigenaar en groep (tenzij je ACLs of MAC toepast
via kernelhacks maar dat is hier niet van toepassing):

-rwx--w---    1 vincent    sites         117 09-24 14:29 pine.cache

Hier heeft vincent (de gebruiker) de lees, schrijf en uitvoerrechten van het
bestand pine.cache (7), sites (de groep) heeft enkel schrijfrechten (2). Al
de rest kan niets doen.

Nu, als je webserver (Apache waarschijnlijk) draait met de permissies van
vincent (de gebruiker) dan zal deze die file dus kunnen bekijken, lezen en
schrijven. Hierdoor kunnen bezoekers dan ook het bestand lezen (schrijven en
uitvoeren gaat niet, Apache laat dat niet toe).

Als de webserver draait met root-permissies, dan kan die uiteraard ook die
bestanden lezen - root kan alles.

Mvg,
	Sven Vermeulen

Dominique Devriese <dominique.devriese@student.kuleuven.ac.be> schreef in 
news:873crz5ykh.fsf@appel.kotnet.org:

> Vincent Spruyt writes:
> 
>> Sven Vermeulen <svenPUNTJEvermeulen@rug.ac.be> schreef in
>> news:%OYj9.130211$8o4.19177@afrodite.telenet-ops.be:
> 
>>> On Tue, 24 Sep 2002 12:13:02 GMT, Vincent Spruyt
>>> <info@computersecurity.be> wrote:
>>>> sorry dat ik zo tegen mezelf praat ;-) Maar wat ik wel nog vreemd
>>>> vind, is, dat de chmod van pine.cache op 720 staat, en toch kan
>>>> iedereen het nog lezen...
>>>
>>> Misschien (hoogstwaarschijnlijk) dat Apache als UID deze van de
>>> eigenaar van pine.cache heeft (of root, dat kan ook).
> 
>> Wat je hier bedoeld begrijp ik niet echt, maar veilig klinkt het
>> niet ;-)
> 
> UNIX toegangscontrole bepaalt welke UNIX "user" toegang heeft tot een
> bepaald bestand.  Elk programma draait als een bepaalde user.  Als jij
> inlogt, dan draait je shell als de user waarmee je inlogt.  Apache
> draait ook als een bepaalde user.  Over het algemeen heet deze httpd
> of apache of zo, maar het kan zijn ( als je sysadmin zijn vak niet
> kent ) dat deze als root draait.
> De file-permissies 720 bepalen dat de eigenaar van het bestand het
> bestand mag uitvoeren ( ?? )

Wel ja, 620 werkt ook ;-)

> , lezen en schrijven, en dat de groep
> waarvan het eigendom is, het bestand mag schrijven ( ?? ),

Yupz die vraagtekens stelde ik me ook... (wat raar uitgedrukt maar soit 
;-)
Mijn script kan het bestand alleen maar aanmaken als de group write 
access heeft! Maw... als iemand zich bij basm registreerd heeft ie write 
access op mijn bestand, of vergis ik me? Gaat niet anders bij basm.

> maar niet
> lezen en uitvoeren.  Users die niet tot die groep behoren mogen niets
> doen met het bestand.
> Waarschijnlijk is het bestand in kwestie eigendom van de user apache
> of httpd, ofwel draai je apache als root.

Zou het niet beter zijn het script of bestand eigendom van mijn user te 
maken? Dan moet ik de group geen privileges geven... nu is dat wel nodig. 
Waarschijnlijk is het script dus eigendom van de group...?
Verder zou, als ik het goed begrijp, een mogelijke oplossing zijn het 
script buiten de webroot te plaatsen, maar dat is niet toegelaten bij 
BASM.

> Dat laatste zou erg dom
> zijn, maar je permissies staan ook vrij raar, dus misschien heb je er
> wel wat mee zitten knoeien ?

Heb er uiteraard mee zitten knoeien. Was ook nodig. Het bestand kan 
alleen aangemaakt (en later overschreven) worden als het aangemaakte 
bestand chmod 620 meekrijgt.
Wat ik vreemd (en misschien gevaarlijk?) vind is dus

- Group moet write access krijgen als ik een bestand wil laten aanmaken 
en later ook wil wijzigen.
- Ook wanner group en other geen read permission hebben, kunnen ze het 
bestand toch lezen.

-- 
Computer games don't affect kids; I mean if Pac-Man affected us as kids, 
we'd all be running around in darkened rooms, munching magic pills and 
listening to repetitive electronic music. (Christian Wilson)
		- <url:http://www.computersecurity.be/> -

Sven Vermeulen <svenPUNTJEvermeulen@rug.ac.be> schreef in
news:KvZj9.130248$8o4.19384@afrodite.telenet-ops.be: 

> On Tue, 24 Sep 2002 12:27:32 GMT, Vincent Spruyt
> <info@computersecurity.be> wrote:
> [... file perms 720, iedereen kan ze leven via internet ...]
>>  Wat je hier bedoeld begrijp ik niet echt, maar veilig klinkt het
>>  niet ;-) 
> 
> Je file heeft een bepaalde eigenaar en groep (tenzij je ACLs of MAC
> toepast via kernelhacks maar dat is hier niet van toepassing):
> 
> -rwx--w---    1 vincent    sites         117 09-24 14:29 pine.cache
> 
> Hier heeft vincent (de gebruiker) de lees, schrijf en uitvoerrechten
> van het bestand pine.cache (7), sites (de groep) heeft enkel
> schrijfrechten (2). Al de rest kan niets doen.
> 
> Nu, als je webserver (Apache waarschijnlijk) draait met de permissies
> van vincent (de gebruiker) dan zal deze die file dus kunnen bekijken,
> lezen en schrijven. Hierdoor kunnen bezoekers dan ook het bestand
> lezen (schrijven en uitvoeren gaat niet, Apache laat dat niet toe).
> 
> Als de webserver draait met root-permissies, dan kan die uiteraard ook
> die bestanden lezen - root kan alles.

Dus ofwel draait de webserver van BASM onder root, ofwel onder dezelfde 
privileges als de gebruikers... rws dus. right? Lijkt me toch niet erg 
veilig.

-- 
Computer games don't affect kids; I mean if Pac-Man affected us as kids, 
we'd all be running around in darkened rooms, munching magic pills and 
listening to repetitive electronic music. (Christian Wilson)
		- <url:http://www.computersecurity.be/> -

Vincent Spruyt <info@computersecurity.be> schreef in 
news:Xns92939BB3C6B69www.computersecurity@195.130.132.65:

> Sven Vermeulen <svenPUNTJEvermeulen@rug.ac.be> schreef in
> news:KvZj9.130248$8o4.19384@afrodite.telenet-ops.be: 
> 
>> On Tue, 24 Sep 2002 12:27:32 GMT, Vincent Spruyt
>> <info@computersecurity.be> wrote:
>> [... file perms 720, iedereen kan ze leven via internet ...]
>>>  Wat je hier bedoeld begrijp ik niet echt, maar veilig klinkt het
>>>  niet ;-) 
>> 
>> Je file heeft een bepaalde eigenaar en groep (tenzij je ACLs of MAC
>> toepast via kernelhacks maar dat is hier niet van toepassing):
>> 
>> -rwx--w---    1 vincent    sites         117 09-24 14:29 pine.cache
>> 
>> Hier heeft vincent (de gebruiker) de lees, schrijf en uitvoerrechten
>> van het bestand pine.cache (7), sites (de groep) heeft enkel
>> schrijfrechten (2). Al de rest kan niets doen.
>> 
>> Nu, als je webserver (Apache waarschijnlijk) draait met de permissies
>> van vincent (de gebruiker) dan zal deze die file dus kunnen bekijken,
>> lezen en schrijven. Hierdoor kunnen bezoekers dan ook het bestand
>> lezen (schrijven en uitvoeren gaat niet, Apache laat dat niet toe).
>> 
>> Als de webserver draait met root-permissies, dan kan die uiteraard ook
>> die bestanden lezen - root kan alles.
> 
> Dus ofwel draait de webserver van BASM onder root, ofwel onder dezelfde 
> privileges als de gebruikers... rws dus. right? Lijkt me toch niet erg 
> veilig.

Verder moet trouwens de map waar het script en het bestand inzitten 730 
chmod hebben.

-- 
Computer games don't affect kids; I mean if Pac-Man affected us as kids, 
we'd all be running around in darkened rooms, munching magic pills and 
listening to repetitive electronic music. (Christian Wilson)
		- <url:http://www.computersecurity.be/> -

Vincent Spruyt writes:

> Dominique Devriese <dominique.devriese@student.kuleuven.ac.be>
> schreef in news:873crz5ykh.fsf@appel.kotnet.org:
>> Vincent Spruyt writes:
>>
>>> Sven Vermeulen <svenPUNTJEvermeulen@rug.ac.be> schreef in
>>> news:%OYj9.130211$8o4.19177@afrodite.telenet-ops.be:
>>
>>>> On Tue, 24 Sep 2002 12:13:02 GMT, Vincent Spruyt
>>>> <info@computersecurity.be> wrote:
>>>>> sorry dat ik zo tegen mezelf praat ;-) Maar wat ik wel nog
>>>>> vreemd vind, is, dat de chmod van pine.cache op 720 staat, en
>>>>> toch kan iedereen het nog lezen...
>>>>
>>>> Misschien (hoogstwaarschijnlijk) dat Apache als UID deze van de
>>>> eigenaar van pine.cache heeft (of root, dat kan ook).
>>
>>> Wat je hier bedoeld begrijp ik niet echt, maar veilig klinkt het
>>> niet ;-)
>>
>> UNIX toegangscontrole bepaalt welke UNIX "user" toegang heeft tot
>> een bepaald bestand.  Elk programma draait als een bepaalde user.
>> Als jij inlogt, dan draait je shell als de user waarmee je inlogt.
>> Apache draait ook als een bepaalde user.  Over het algemeen heet
>> deze httpd of apache of zo, maar het kan zijn ( als je sysadmin
>> zijn vak niet kent ) dat deze als root draait.  De file-permissies
>> 720 bepalen dat de eigenaar van het bestand het bestand mag
>> uitvoeren ( ?? )

> Wel ja, 620 werkt ook ;-)

>> , lezen en schrijven, en dat de groep waarvan het eigendom is, het
>> bestand mag schrijven ( ?? ),

> Yupz die vraagtekens stelde ik me ook... (wat raar uitgedrukt maar
> soit
> ;-)
> Mijn script kan het bestand alleen maar aanmaken als de group write
> access heeft! Maw... als iemand zich bij basm registreerd heeft ie
> write access op mijn bestand, of vergis ik me? Gaat niet anders bij
> basm.

hm.. maakte jij eigenlijk geen site op www.computersecurity.be ? ;) 

sorry dat ik niet kan volgen, maar kan je ff uitleggen wat basm is ?

>> maar niet lezen en uitvoeren.  Users die niet tot die groep behoren
>> mogen niets doen met het bestand.  Waarschijnlijk is het bestand in
>> kwestie eigendom van de user apache of httpd, ofwel draai je apache
>> als root.

> Zou het niet beter zijn het script of bestand eigendom van mijn user
> te maken? Dan moet ik de group geen privileges geven... nu is dat
> wel nodig.

je bedoelt het script draaien als je eigen user ?  Lijkt me een goed
idee, waarom niet ?  Of misschien een eigen user geven "scripty",
pine.cache eigendom van die user maken, en het bestand permissies 644
geven ?

> Waarschijnlijk is het script dus eigendom van de
> group...?  Verder zou, als ik het goed begrijp, een mogelijke
> oplossing zijn het script buiten de webroot te plaatsen, maar dat is
> niet toegelaten bij BASM.

hoezo ?

>> Dat laatste zou erg dom zijn, maar je permissies staan ook vrij
>> raar, dus misschien heb je er wel wat mee zitten knoeien ?

> Heb er uiteraard mee zitten knoeien. Was ook nodig. Het bestand kan
> alleen aangemaakt (en later overschreven) worden als het aangemaakte
> bestand chmod 620 meekrijgt.  Wat ik vreemd (en misschien
> gevaarlijk?) vind is dus

> - Group moet write access krijgen als ik een bestand wil laten
>   aanmaken
> en later ook wil wijzigen.

Kort samengevat moet je script schrijfrechten hebben, en de webserver
leesrechten ?  Zo moeilijk kan dat toch niet zijn, zie hierboven..

> - Ook wanner group en other geen read permission hebben, kunnen ze
>   het bestand toch lezen.

Ah ja..  Dus je hebt net een enorm zware permissie-fout in je kernel
ontdekt ?  I think not ;)  Kan je even uitleggen hoe je tot die
conclusie komt ?
sjuus
domi

-- 
You will triumph over your enemy.

Vincent Spruyt writes:
> Verder moet trouwens de map waar het script en het bestand inzitten
> 730 chmod hebben.

eerder 740, als ik het goed begrepen heb..
sjuus
domi

-- 
You'd like to do it instantaneously, but that's too slow.

Dominique Devriese <dominique.devriese@student.kuleuven.ac.be> schreef in 
news:87adm7xyy2.fsf@appel.kotnet.org:

> Vincent Spruyt writes:

>> Mijn script kan het bestand alleen maar aanmaken als de group write
>> access heeft! Maw... als iemand zich bij basm registreerd heeft ie
>> write access op mijn bestand, of vergis ik me? Gaat niet anders bij
>> basm.
> 
> hm.. maakte jij eigenlijk geen site op www.computersecurity.be ? ;) 

Geen zin om nog eens hetzelfde te reageren ;-) Antwoord vind je hier:
news: <Xns9292DC01D9BB5www.computersecurity@195.130.132.65>
 
> sorry dat ik niet kan volgen, maar kan je ff uitleggen wat basm is ?

Ow sorry. Hostingsprovider. (www.basm.be)

>>> maar niet lezen en uitvoeren.  Users die niet tot die groep behoren
>>> mogen niets doen met het bestand.  Waarschijnlijk is het bestand in
>>> kwestie eigendom van de user apache of httpd, ofwel draai je apache
>>> als root.
> 
>> Zou het niet beter zijn het script of bestand eigendom van mijn user
>> te maken? Dan moet ik de group geen privileges geven... nu is dat
>> wel nodig.
> 
> je bedoelt het script draaien als je eigen user ?  Lijkt me een goed
> idee, waarom niet ?  Of misschien een eigen user geven "scripty",
> pine.cache eigendom van die user maken, en het bestand permissies 644
> geven ?

Wel ja, maar Basm gaat me dat niet laten doen ;-)
Op zich geen probleem, want ik stap toch over naar solidweb 
(www.solidweb.be), maar het lijkt me dus dat BASM nogal steken laat 
vallen in hun securitybeleid...
 
>> Waarschijnlijk is het script dus eigendom van de
>> group...?  Verder zou, als ik het goed begrijp, een mogelijke
>> oplossing zijn het script buiten de webroot te plaatsen, maar dat is
>> niet toegelaten bij BASM.
> 
> hoezo ?

Tjah, gaat gewoon niet bij deze hostingprovider ;-)

> 
>>> Dat laatste zou erg dom zijn, maar je permissies staan ook vrij
>>> raar, dus misschien heb je er wel wat mee zitten knoeien ?
> 
>> Heb er uiteraard mee zitten knoeien. Was ook nodig. Het bestand kan
>> alleen aangemaakt (en later overschreven) worden als het aangemaakte
>> bestand chmod 620 meekrijgt.  Wat ik vreemd (en misschien
>> gevaarlijk?) vind is dus
> 
>> - Group moet write access krijgen als ik een bestand wil laten
>>   aanmaken
>> en later ook wil wijzigen.
> 
> Kort samengevat moet je script schrijfrechten hebben, en de webserver
> leesrechten ?  Zo moeilijk kan dat toch niet zijn, zie hierboven..

idd, maar ik kan niets veranderen aan de configuratie van BASM.

> 
>> - Ook wanner group en other geen read permission hebben, kunnen ze
>>   het bestand toch lezen.
> 
> Ah ja..  Dus je hebt net een enorm zware permissie-fout in je kernel
> ontdekt ?  I think not ;)  Kan je even uitleggen hoe je tot die
> conclusie komt ?

heb ik niet beweerd he.
Ik kom tot die conclusie omdat ik het uitgeprobeerd heb...
Bij basm is het gewoon zo dat ik group een write access moet geven om het 
script een bestand kunnen laten aanmaken. Verder is het ook zo dat een 
bestand waarbij group en other geen read access hebben toch gelezen kan 
worden door iedereen.
volgennde url is het aangemaakte bestand met chmod 620. Read access staat 
dus niet aan voor other en group.
http://www.computersecurity.be/test/pine.cache
en toch kan iedereen het lezen...



-- 
Computer games don't affect kids; I mean if Pac-Man affected us as kids, 
we'd all be running around in darkened rooms, munching magic pills and 
listening to repetitive electronic music. (Christian Wilson)
		- <url:http://www.computersecurity.be/> -

On 24 Sep 2002 16:11:23 +0200, Dominique Devriese
<dominique.devriese@student.kuleuven.ac.be> wrote:
>  eerder 740, als ik het goed begrepen heb..

Eigenlijk kan Apache (de webserver) onder eender welke UID draaien, zijn GID
is deze van basm (of wat was het ook weer):
	- hij moet schrijf en uitvoerrechten hebben op de dir (-wx = 3)
	- hij moet schrijfrechten hebben op het bestand (-w- = 2)

Die zaken zijn vervuld voor de groep.

Dat is niet iets "onveilig", itt, dit is eigenlijk meer dan normaal. Een
webserver draait vaak met GID die van de groep waar de sites tot behoren
maar UID bv "apache" of "nobody"...

Mvg,
	Sven Vermeulen

Dominique Devriese <dominique.devriese@student.kuleuven.ac.be> schreef in 
news:8765wvxyt0.fsf@appel.kotnet.org:

> Vincent Spruyt writes:
>> Verder moet trouwens de map waar het script en het bestand inzitten
>> 730 chmod hebben.
> 
> eerder 740, als ik het goed begrepen heb..

nope, 730 werkt prima. Het bestand heeft ook geen read access he.
Dat is nu net het vreemde. Read access staat af voor zowel group als other, 
en toch...


-- 
Computer games don't affect kids; I mean if Pac-Man affected us as kids, 
we'd all be running around in darkened rooms, munching magic pills and 
listening to repetitive electronic music. (Christian Wilson)
		- <url:http://www.computersecurity.be/> -

Sven Vermeulen <svenPUNTJEvermeulen@rug.ac.be> schreef in
news:K6%j9.130372$8o4.19296@afrodite.telenet-ops.be: 

> On 24 Sep 2002 16:11:23 +0200, Dominique Devriese
> <dominique.devriese@student.kuleuven.ac.be> wrote:
>>  eerder 740, als ik het goed begrepen heb..
> 
> Eigenlijk kan Apache (de webserver) onder eender welke UID draaien,
> zijn GID is deze van basm (of wat was het ook weer):
>      - hij moet schrijf en uitvoerrechten hebben op de dir (-wx = 3)
>      - hij moet schrijfrechten hebben op het bestand (-w- = 2)
> 
> Die zaken zijn vervuld voor de groep.
> 
> Dat is niet iets "onveilig", itt, dit is eigenlijk meer dan normaal.
> Een webserver draait vaak met GID die van de groep waar de sites tot
> behoren maar UID bv "apache" of "nobody"...

wel ja, maar het probleem is nu net dat de read access overal afstaat, en 
dat het bestand toch gelezen kan worden. Ik zeg niet dat je bvb .htaccess 
niet kan gebruiken om de bestanden te beveiligen, maar is het niet raar 
dat iedereen bestanden kan lezen waar ze geen read access toe zouden 
mogen hebben? Lijkt wel of de bezoekers als owner worden gezien...

-- 
Computer games don't affect kids; I mean if Pac-Man affected us as kids, 
we'd all be running around in darkened rooms, munching magic pills and 
listening to repetitive electronic music. (Christian Wilson)
		- <url:http://www.computersecurity.be/> -

On Tue, 24 Sep 2002 15:03:29 GMT, Vincent Spruyt <info@computersecurity.be>
wrote:
>  wel ja, maar het probleem is nu net dat de read access overal afstaat, en 
>  dat het bestand toch gelezen kan worden. Ik zeg niet dat je bvb .htaccess 
>  niet kan gebruiken om de bestanden te beveiligen, maar is het niet raar 
>  dat iedereen bestanden kan lezen waar ze geen read access toe zouden 
>  mogen hebben? Lijkt wel of de bezoekers als owner worden gezien...

De fuck, te laat bericht gecancelled...

	Sven Vermeulen  

Sven Vermeulen <svenPUNTJEvermeulen@rug.ac.be> schreef in
news:Cc%j9.130378$8o4.19382@afrodite.telenet-ops.be: 

> On Tue, 24 Sep 2002 15:03:29 GMT, Vincent Spruyt
> <info@computersecurity.be> wrote:
>>  wel ja, maar het probleem is nu net dat de read access overal
>>  afstaat, en dat het bestand toch gelezen kan worden. Ik zeg niet dat
>>  je bvb .htaccess niet kan gebruiken om de bestanden te beveiligen,
>>  maar is het niet raar dat iedereen bestanden kan lezen waar ze geen
>>  read access toe zouden mogen hebben? Lijkt wel of de bezoekers als
>>  owner worden gezien... 
> 
> De fuck, te laat bericht gecancelled...

neenee, ik was te vroeg terug van de winkel ;-)


-- 
Computer games don't affect kids; I mean if Pac-Man affected us as kids, 
we'd all be running around in darkened rooms, munching magic pills and 
listening to repetitive electronic music. (Christian Wilson)
		- <url:http://www.computersecurity.be/> -

Vincent Spruyt schreef:

>> $filemod = filemtime("pine.cache");
> 
> of toch! bedankt!

Dat was toch hetgeen ik had geschreven?
"Gewoon je $filemod vergelijken met $tijd - 1u... "

Wie gaat nu z'n tijd omzetten naar een ander formaat als het toch maar 
is om een simpele vergelijking uit te voeren (:


Jeffrey
-- 
.: PEBBELS : het klikt tussen ons :.
: www.pebbels.be .. irc.pebbels.be :

Jeffrey Drooghenbroodt <jeffrey@pebbels.be> schreef in 
news:Xns9293B3867ECDCIIjeffrey@pebbels.be:

> Vincent Spruyt schreef:
> 
>>> $filemod = filemtime("pine.cache");
>> 
>> of toch! bedankt!
> 
> Dat was toch hetgeen ik had geschreven?
> "Gewoon je $filemod vergelijken met $tijd - 1u... "
> 
> Wie gaat nu z'n tijd omzetten naar een ander formaat als het toch maar 
> is om een simpele vergelijking uit te voeren (:

idd ;-) maar omdat ik het had over het andere formaat wist ik niet dat jij 
over de unixtimestamp bezig was ;-)

-- 
Computer games don't affect kids; I mean if Pac-Man affected us as kids, 
we'd all be running around in darkened rooms, munching magic pills and 
listening to repetitive electronic music. (Christian Wilson)
		- <url:http://www.computersecurity.be/> -

Vincent Spruyt writes:

> Dominique Devriese <dominique.devriese@student.kuleuven.ac.be>
> schreef in news:8765wvxyt0.fsf@appel.kotnet.org:

>> Vincent Spruyt writes:
>>> Verder moet trouwens de map waar het script en het bestand
>>> inzitten 730 chmod hebben.
>>
>> eerder 740, als ik het goed begrepen heb..

> nope, 730 werkt prima. Het bestand heeft ook geen read access he.
> Dat is nu net het vreemde. Read access staat af voor zowel group als
> other, en toch...

je wilt de group toelaten om naar de directory te schrijven en hem uit
te voeren.  Ik moet toegeven dat ik zelf altijd weer vergeet wat die
permissies nu weer betekenen voor directories, maar:
Schrijftoegang gaat om het toelaten van het verwijderen en hernoemen
van files in de directory.  Je scriptje heeft dit niet nodig.
Execute-toegang gaat om het toelaten van cd-en naar die directory.
Dat kan je idd beter toelaten.
Leestoegang gaat om het bekijken van welke files er in de directory
staan.  Dit heeft je scriptje niet per se nodig, maar je weet maar
nooit, zeker...

710 lijkt me dus van toepassing, oftewel 750
sjuus
domi
-- 
You tread upon my patience.
		-- William Shakespeare, "Henry IV"

Vincent Spruyt writes:

> Sven Vermeulen <svenPUNTJEvermeulen@rug.ac.be> schreef in
> news:K6%j9.130372$8o4.19296@afrodite.telenet-ops.be:

>> On 24 Sep 2002 16:11:23 +0200, Dominique Devriese
>> <dominique.devriese@student.kuleuven.ac.be> wrote:
>>> eerder 740, als ik het goed begrepen heb..
>>
>> Eigenlijk kan Apache (de webserver) onder eender welke UID draaien,
>> zijn GID is deze van basm (of wat was het ook weer):
>> - hij moet schrijf en uitvoerrechten hebben op de dir (-wx = 3)
>> - hij moet schrijfrechten hebben op het bestand (-w- = 2)
>>
>> Die zaken zijn vervuld voor de groep.
>>
>> Dat is niet iets "onveilig", itt, dit is eigenlijk meer dan
>> normaal.  Een webserver draait vaak met GID die van de groep waar
>> de sites tot behoren maar UID bv "apache" of "nobody"...

> wel ja, maar het probleem is nu net dat de read access overal
> afstaat, en dat het bestand toch gelezen kan worden. Ik zeg niet dat
> je bvb .htaccess niet kan gebruiken om de bestanden te beveiligen,
> maar is het niet raar dat iedereen bestanden kan lezen waar ze geen
> read access toe zouden mogen hebben? Lijkt wel of de bezoekers als
> owner worden gezien...

je begrijpt het verkeerd.  UNIX permissies gaat om programma's die de
harde schijf benaderen.  In dit geval het Apache programma.  Dit
draait blijkbaar als een gebruiker die toegang heeft tot de file in
kwestie.  De toegang die websurfers hebben tot de file _via_ de
webserver, is iets totaal anders, en het is enkel Apache die daar iets
over te zeggen heeft.  De kernel heeft daar namelijk absoluut geen
weet van.  Al wat de kernel "ziet" is een programma dat als user root
draait ( of hoe zit het nu ?), en dat een bestand probeert te
lezen, wat hij om allerhande redenen toelaat.
sjuus
domi

-- 
You'll feel devilish tonight.  Toss dynamite caps under a flamenco dancer's
heel.