World: r3wp

yes, I run it with -cs, or it gives REBOL - security violation message 
....

I am going for cgi-based template system, and I expect to use index.cgi 
in my doc-root directory ....

can you write something in /tmp? there everyone can write usually.

well, yes, I will probably fix ti by redirecting logging, it is just 
that I would like the sqlite driver to work in such cases, as sqlite 
is cool, handy, and I will have to adapt the source with each release. 
So I would expect setting log?: false to take care of disabling logging 
;-)

i understand. but i never looked in sqlite :)

well, it is really handy ... it is SQL, that is importand ... and 
it is completly portable - imagine having small apps, you just need 
cgi-bin site and you can have your rebol app wherever .... no need 
for admin to configure mysql for you, etc., I like it. For small 
to middle stuff it is pretty ok ...

i would set log-path to %/tmp/, make sure /tmp/sqlite.log does not 
exist  and give it a last try.

actually i rarelly looked in any sql, as for my simple uses files 
are enough.

else i would look in sqlite, because the people here like it :)

yes, of course, no problems. I really liked RebDB - imo really cool 
piece of code ... but unless you need join multiple tables and have 
some more relations ....

or need locking or.., like you, then yes :)

ok, going to sleep, 1:45 am here :-) Commented logging on few places 
in driver ...

me too. good night.

good night! :-)

Petr, most likely the apache user cannot write the log file. you 
can create the log file (with touch) and chown it to the apache user.

Gabriele - not sure it is a typical log file. It is just file sqlite 
driver writes via write/new/append into current-dir, if not set oterwise 
....

I expected that once I am running rebpro -cs, I can write to files 
too .... I tried to change location of sqlite.log file, to cgi-bin, 
where write should be allowed, but still not luck. Maybe I just need 
specific Apache dir directive setting to allow that? Dunno .... so 
I commented out logging - just 4 lines or so .... I will try Ashley's 
suggestion for setting it to dev\nul ...

it's not rebol that can't write because of -s, it's the apache user 
not having permissions (from what you describe). generally apache 
never has write access to cgi-bin because that's a security risk. 
you can give it access to that single file (still risky) or move 
the file to /var/log for e.g. where apache keeps its other log files.

thanks ....

I just verified .... it is definitely problem with permissions on 
files, and I am having headache because of it already (maybe linux 
is really not for me :-)

when I run Apache and my virtual host with SuexecUserGroup jablunkovsko 
jabladm, I can't run CGI at all, and that is strange! All directories 
and files are of owner=jablunkovsko, group=jabladm, including rebpro, 
rsp.cgi

Simple commenting out Suexec directive enables me to run CGI ... 
but still not luck writing to file. My friend suggested me to add 
../db/ dir permissions of 777, to see what happens. Then yes, I can 
see %log.txt generated, owner and group is apache ....

but - log.txt is just an example. It is not option for me to have 
files I want to write to placed somewhere else, as I will/want to 
use sqlite and surely want it have accessible via ftp easily, directly 
in directory I want.

what I wonder is - why it is not enough to set chmod 666 for that 
directory? It clearly states that everybody can read and write in 
/db/ directory ....

setting it to 777 sounds possible, but kind of masochistic to me 
:-)

I also played with setuid etc. settings, to have Apache using particular 
permissions of /db/ directory, but still not luck ....

hmm, now I tried su apache, and my sestem tells me, that there is 
no such an user. Could that be a problem? That server was set-up 
for me some 3 years ago, so I don't remember properly, how it was 
configured ....

hmm, the account is there, it is just it has probably set /sbin/nologin 
in passwd ...

Hmm, I allowed for user apache to log in, I can get to each directory, 
but "cd db" returns "permission denied" - why it is so?

drwxr-sr-x  2 jablunkovsko jabladm  4096 Jan 11  2005 about
drwxr-sr-x  4 jablunkovsko jabladm  4096 Aug  7 16:04 akce
drwxr-sr-x  3 jablunkovsko jabladm  4096 Jul  3 20:03 aktuality
drwxr-xr-x  2 jablunkovsko jabladm  4096 Aug  6 19:01 cgi-bin
drwxr-sr-x  3 jablunkovsko jabladm  4096 Nov  2  2005 COD
drwxr-sr-x  5 jablunkovsko jabladm  4096 Jul  3 20:04 cyklo
drwxr-sr-x  2 jablunkovsko jabladm  4096 Aug  2 00:04 data
drw-rw-rw-  2 jablunkovsko jabladm  4096 Aug  7 14:29 db
drwxr-sr-x  4 jablunkovsko jabladm  4096 Jul  3 20:05 fotogalerie

setting permission to executable for a directory allows you to enter 
it

btw - what is the difference in "s" and "S"? I don't remember how 
those "s" got in there. Are those user/grup id? If I set such manually, 
I get "S", not "s".

why can I enter each other dir, but not db dir?

ah, got it ...

so to enter directory, I need to set x bit for it?

but not necessarily for files inside, right?

is setting recursively "s" option for files and diretories good to 
achieve correct user/group ids when copying via ftp? Or it is not 
necessary?

I think that I don't need those "s" bits, but before I remove it, 
I better ask :-)

group "s" on a dir  says that by default; all  files and dirs created 
below me will have the same  group ownership/perms that I have.

thanks ... the problem probably was, that for a directory, there 
needs to be "execute" bit set, or you can't enter it ...

and is there difference between small and capital "s"?

yes the entire path of dirs to your target  need to be executable 
to get there

lower s it the "sticky" bit for dirs to cause item under them to 
take on the same permissions and ownership
only applies to directories owner and group (but effects files)


upper case S I am not recalling off the top of my head ... applies 
to files  scriptable or sockets or something

I thought the sticky bit is T?

but I understand what you mean ...

on dirs, read means you can list the contents, write means you can 
remove/add files to the dir, and execute means you can access the 
files in the dir.

what do you mean "access files in the dir"?

the strange thing was, that I was able to read directory content 
and print it to the browser, just write %../db/log.txt failed ....

and I had "write" enabled - rw-rw-rw (666) ....

on solaris sticky bit is 's'  i would be suprised if linux strayed 
that much

write access means you can add files to the dir, but to write on 
them you need to be able to access files in the dir which is the 
execute bit. i think you can probably use the touch command to create 
new files on dirs with rw- (not sure though) but for complete access 
to a dir you need rwx.