Hi,

I have an archive for radio stations running in a number of places. Recently we've been advised that any downloadable file is a potential copyright infringement (assuming there's copyrighted material in the file).

As a result, I've written a server in 'c' so an mp3 can be delivered from above the docroot. It's your basic socket-type unix server which responds to a request on the port it's bound to.

On my site (kpftx.org/kuleft) it works fine as long as I run it from the login. I've written extensive php to control this server, move files from accessible directory to private and back, etc. All works on my own linux box (Fedora 2). On the server, however, if I start the server from the web page control, it does not respond to a request from a client. It just stays permanently in 'select()'.

It's not a selinux issue (as far as I can tell - there were a bunch of others but they're handled.

The question: why does a server work when I call it, but not when it's called by apache?

Thanks in advance for any assistance, help or pointing out how poor my code is.

O.

Otis Maclay
Houston

I think you already provided solution in your problem itself.

Problem is with permission issues.
Apache user/group is not having permission to read/execute your 'C' server binaries.

Please check whether
1. Apache user/group has permission to directory where server files resides.
2. Apache has permission to execute binaries ( if there are ).
3. Check whether you are using absolute path/relative path and its accessible by Apache.

Please update us if you still have problems.

thanks for your reply, pratik
sorry to be so long replying to your suggestion - away

Unfortunately, it is deeper than permissions:

The server runs and binds to the port and shows up as 'LISTENING' in netinfo

It just never responds to a request unless started under the login as opposed to apache (the uid of the apache server)

Nothing shows up in /var/log/messages, which seems to indicate that it isn't a selinux question.

a: could it be an apache config issue?
b: could it be some secret selinux issue?

FYI, I also ran it as a root setuid and an apache setuid - made no difference.

Thanks for you response,

O.