phpMyAdmin problem: with suexec, nothing but the login screen 1

[OsakaWebbie]

I'm setting up a VPS with CentOS 5.6 and PHP 5.3.3 running as FastCGI. I have phpMyAdmin installed in a subdirectory of my main domain, and initially it was working fine. But I want to use suexec because of Joomla (so I can write files safely), so I set up all the file ownerships and such so that that worked fine for my Joomla-based website. But now I can't log into phpMyAdmin - apparently some session-related problem. I get no useful feedback, though - it just refreshes the login page with no error messages or anything. Joomla is working fine with suexec on, including logging into the admin interface, which I would think would use the same kind of functionality (cookie/session) as PMA. The only thing I have to do to successfully log into PMA is to comment out the line in my Apache configuration for the virtualhost that says, "suexecUserGroup myuser mygroup", but that's not good for the rest of my setup, because PHP would then do file operations as the default Apache user.

I don't know if this is the right forum for this question, or if I need to find something more server related, but I'll start here.

 

[jpadie]

Two potential solutions (not tried either myself). These assume that this is a manual install of phpmyadmin and not a repo install.

1. Ensure all pma files are owned the suexec owner and then symlink the directory into your server root
2. Turn off suexec for the pma directory.

and in any event ensure that the session storage directory has open perms (777 or similar). Typically centos does not use /tmp for session storage but, from recollection, /var/lib/php/sessions.

If the above does not work then it may be because of the auth method that phpmyadmin is using. Disabling suexec for pma should fix this but if not (or if you want suexec for pma) then a nasty kludge might be to create an autoprepend file that auto populates a global variable

<?php
$_SERVER['SCRIPT_NAME'] = $_SERVER['SCRIPT_URL'];

Warning: not tested at all as I'm nowhere near a computer at the moment.

 

[OsakaWebbie]

...I'm nowhere near a computer at the moment.

That gave me a chuckle - how then, did you write your post? (I know what you mean: a computer on which you can play around on the command line.)


Anyway, back to the topic. Indeed, upon investigation, the /var/lib/php/session directory (no "s" on the end, it turns out) had permissions of 770 (and was owned by apache:apache), so loosening that solved the problem. I don't like making things 777, but at least the session files themselves are still all 600.

That caused me to wonder why Joomla and a session-based app I wrote had both been working okay. It turns out that Joomla stores its sessions in its database rather than a file, and for some reason my app (which is on a subdomain with a separate virtualhost entry) was not really doing suexec yet - I have no idea why, but after moving things around in my config file a bit, it started switching properly to the user I assigned to it.

Thanks!

 

[jpadie]

glad you're fixed. (btw, was posted from an iphone)

an alternative to making it 0777 would be to chgrp the session dir to a new group, and then add the apache user and the suexec user to the group.
but as you hint, not really necessary since it's only the directory that is 777, the files are created with the suexec user perms on them (or at least should be).

storing session data in a db is a great idea when you're using squid or some other traffic manager and can't be sure of which box a request will hit. otherwise i think i'd rather store vanilla session data in the filesystem (meta data that needs to persist, of course, in a database). but i've changed my mind on this a few times in the past.

 

[OsakaWebbie]

Well, I didn't design Joomla - they made their own decision to use the database. I have never even considered doing that in my code - the session functions are already in PHP, easy to use, and they work (the old adage, "If it works, don't fix it"). On the other hand, I have hand-coded many things that later people came along and made cool functions to do. For example, before AJAX was a gleam is his mother's eye, I invented something similar using the tools I had available to me, making JS call a popup to do my PHP work and immediately changing focus to the parent so the popup would hide in the background until it closed itself. Now with XMLHttpRequest, everyone is doing it!

Ah, an iPhone! I tend to forget that people actually puruse full-blown websites on such small devices - my eyes are too old for that. But I'm glad you do it, because you helped me solve my problem!

 

[jpadie]

just fyi, for database sessions you still use php functions like session_start() and the implicit assignments

if(session_id() == '') session_start();
$_SESSION['myvar'] = 'myvalue';

the difference is you just register an alternative session handler. check out these links for an explanation and an example

http://www.php.net/manual/en/function.session-set-save-handler.php

http://tek-tips.com/faqs.cfm?fid=2037