[deadline]

Hello,

I have strange behaviour with etomite v1.1 on a new server (on 2 websites) - I just installed the full package -> the install went fine,

After editing some pages, the web pages did not render anymore into the browser... this behaviour appeared to any page, and whatever settings I tried into the configuration panel.

I thought the pb was related to the eto caching system, but the page is clearly malformed... only the etoNotice is displayed !! the source code of any rendered page resumes to :
<div id='etoNotice'>
Powered by <a href='http://www.etomite.com' title='Powered by the Etomite Content Management System'>Etomite CMS</a>.
</div>
So I checked twice the rights to cache directory. those settings are Ok.
Anyway I deselected the caching of the pages... same issue !!

It is not a browser issue, tested on IE 6, 7 and FF

The problem seems related to etomite not being able to sync to the menuPanel. Very Strange

Maybe a pb with my server configuration... but it seems to only affect Etomite.

My Server configuration is as follows :

Debian ETCH 2.6.25.4 - 64 bits
Apache : Apache/2.2.3
php : 5.2.0-8+etch13
MySQL : 5.0.32-Debian_7etch8
Etomite : Prelude v1.1.1

Anybody experiencing the same problem ?
Thank you for your feedback.

deadline.

[deadline]

More,

Exploring the assets/cache directory...

the files :
etomiteCache.idx.php
and
etomitePublishing.idx

have a size of 0...

Hmmmm, I just deleted those 2 files, and then edited a random page from the eto panel... everything works Ok now.

So my assumption is... that there's some code that truncates those cached index files.
Will try to keep track of a reproductible action that leads to the same behaviour.

deadline.

[deadline]

Well, strange... I use Apache with a suexec wrapper... and those cached file are created with default Apache User and Group Ids...

Ralph, do you think there might be a way for Etomite to bypass my wrapper settings ?

Thank you.

[Cris D.]

Interesting, I have never seen this before. Reading the Apache documentation on setting this up, it seems that there is a lot to do and check:

http://httpd.apache....1.3/suexec.html

Quote

1. Was the wrapper called with the proper number of arguments?

The wrapper will only execute if it is given the proper number of arguments. The proper argument format is known to the Apache web server. If the wrapper is not receiving the proper number of arguments, it is either being hacked, or there is something wrong with the suEXEC portion of your Apache binary.

2. Is the user executing this wrapper a valid user of this system?

This is to ensure that the user executing the wrapper is truly a user of the system.

3. Is this valid user allowed to run the wrapper?

Is this user the user allowed to run this wrapper? Only one user (the Apache user) is allowed to execute this program.

4. Does the target program have an unsafe hierarchical reference?

Does the target program contain a leading '/' or have a '..' backreference? These are not allowed; the target program must reside within the Apache webspace.

5. Is the target user name valid?

Does the target user exist?

6. Is the target group name valid?

Does the target group exist?

7. Is the target user NOT superuser?

Presently, suEXEC does not allow 'root' to execute CGI/SSI programs.

8. Is the target userid ABOVE the minimum ID number?

The minimum user ID number is specified during configuration. This allows you to set the lowest possible userid that will be allowed to execute CGI/SSI programs. This is useful to block out "system" accounts.

9. Is the target group NOT the superuser group?

Presently, suEXEC does not allow the 'root' group to execute CGI/SSI programs.

10. Is the target groupid ABOVE the minimum ID number?

The minimum group ID number is specified during configuration. This allows you to set the lowest possible groupid that will be allowed to execute CGI/SSI programs. This is useful to block out "system" groups.

11. Can the wrapper successfully become the target user and group?

Here is where the program becomes the target user and group via setuid and setgid calls. The group access list is also initialized with all of the groups of which the user is a member.

12. Does the directory in which the program resides exist?

If it doesn't exist, it can't very well contain files.

13. Is the directory within the Apache webspace?

If the request is for a regular portion of the server, is the requested directory within the server's document root? If the request is for a UserDir, is the requested directory within the user's document root?

14. Is the directory NOT writable by anyone else?

We don't want to open up the directory to others; only the owner user may be able to alter this directories contents.

15. Does the target program exist?

If it doesn't exists, it can't very well be executed.

16. Is the target program NOT writable by anyone else?

We don't want to give anyone other than the owner the ability to change the program.

17. Is the target program NOT setuid or setgid?

We do not want to execute programs that will then change our UID/GID again.

18. Is the target user/group the same as the program's user/group?

Is the user the owner of the file?

19. Can we successfully clean the process environment to ensure safe operations?

suEXEC cleans the process' environment by establishing a safe execution PATH (defined during configuration), as well as only passing through those variables whose names are listed in the safe environment list (also created during configuration).

20. Can we successfully become the target program and execute?

Here is where suEXEC ends and the target program begins.

Boy oh boy, it certainly leaves room for human error! Anyway, on the surface, it seems to be a suEXEC issue not an etomite one.

[DeanC]

Etomite can only work with the way the underlying software lets it... suExec is there to protect the underlying system and deeper down software... so obviously we can't do anything that suExec won't let us do, or is designed to protect against...

[deadline]

DeanC, on Apr 14 2009, 10:09 PM, said:

Etomite can only work with the way the underlying software lets it... suExec is there to protect the underlying system and deeper down software... so obviously we can't do anything that suExec won't let us do, or is designed to protect against...

Thanks Dean... I've always used Apache with a wrapper, and I've never got any problem until now...

I will double check my suexec conf...

Thanks for your time
deadline

[deadline]

My config seems to be correct... and my problem remains... will perform other tests (or strace)

I found this link to be usefull (setting Apache + Chroot + FastCGI) :
http://www.seaoffire.net/fcgi-faq.html

deadline

[Cris D.]

By the way the cache is being created but not being read tells me it is a read permissions issue. Can you confirm the permissions of the folder and cache files once etomite has created them? I have a funny feeling that the wrapper is allowing etomite to create the files but not letting them be read because of the standard cache file ownership (and permissions) is been changed by the wrapper. There seems to be a lot of settings in the wrapper config specifically aimed at STOPPING things to run, you say the config is correct, but perhaps you have an underlying assumption about how it is supposed to be set up to work that is not correct?

[EDIT] I just read the link you posted above, The part about auditing the permissions of the "workers" spawned by the wrapper seems like a good area to be digging in- using strace you can check their permissions and confirm the directories where they are being run from. Also, it's interesting to note that chroot will allow multiple mini-server areas to be 777 AND that are not cross-user readable. Perhaps etomite is creating the cache files as user "a" and the browser is trying to read them as user "b", therefore the files can't be read as they are being created or read from another virtual directory.[/EDIT] By the way, this is all very new to me, and I don't profess to have any knowledge about this area at all. Sometimes it takes new eyes or a fresh brain to see things in a new light... If you want me to butt out, just say and I'll go back to my cave :)

This post has been edited by Cris D.: 15 April 2009 - 10:54 PM