Comfiguring Complex Permissions

chestertb · 12-20-2009, 06:54 PM

Hi All,

First, allow me to apologise in advance about the length of this post, but I figure if I don't tell you what we have, you won't be able to help.

We have a proprietary CMS that we use for all of our websites. Last week, our server manager upgraded us to the latest version of Debian and in doing so, we lost the permissions that allowed the CMS to run properly. Unfortunately, the programmer who set it up for us is not contactable, and we can't locate any documentation on his configuration. There's a lesson there, I think.

We have an index.php that lives in all domains. (.../html/index.php). That index.php simply includes the cms index script. (include(/usr/share/ourcms/index.inc.php; )

The ownership of all of the files in the domain directories is set as ouruser : ourcms. (index.php, /css/.., /images/..)

Our CMS is in /usr/share/ourcms.
The ownership of those files is set as root : ourcms.

The directory /usr/share/ourcms is configured as though it was /html/ourcms, so if the browser looks for /ourcms/ascript.php, the server will load it as though it as in the domain directory.

What's happening is...
When we try to run the CMS in this configuration, index.php does not have permission to access /ourcms/index.inc.php.

If we change the ownership of index.php to root : ourcms so that it matches the cms scripts, the cms runs, but its scripts can't see images held in the domain (.../html/imgages/...).

If we change the ownership of the cms scripts to ouruser : ourcms, the CMS runs as designed. However, this creates a security problem because now the cms files can be seen, read and written by scripts in the domain directories.

What we want is...
Any script can be run by a browser calling ourdomain.tld/ourcms/ascript.php.
However, ONLY /index.php (ownership ouruser : ourcms) can access any of the scripts in /usr/share/ourcms. Preferably, index.php can ONLY access .../ourcms/index.inc.php.

Any script in /usr/share/ourcms (ownership root : ourcms) can access any file in ../html (ownership ouruser : ourcms).

Either...
How do I set permissions and file ownerships to achieve the above?
Or
We thought of getting rid of the index.php in the domain all together, placing it in /urs/share/ourcms with matching ownership and configuring the server so that it knows where to look for .../html/index.php. How would we do this, and if this is the better option, then how do we configure the whole setup so that cms scripts can see, read and write files in the domain directories, but not visa versa (except for index.php)?

Thanks
CTB

harry edwards · 12-21-2009, 03:11 PM

It sounds like you need to ensure all files with the web sites permit group level read/write:

Code:

chmod g+rx /path/to/file

And then ensure the user running your web service is within that group. To modify the group of a file or directory you can used the chgrp command.

chestertb · 12-26-2009, 08:22 PM

thanks harry.
done that. no change.
i now suspect the problem is in the groups file, but need a day or so to get my head around the way my server administrator has set it all up.

rnturn · 12-29-2009, 06:16 PM

Quote:

Originally Posted by chestertb

We have a proprietary CMS that we use for all of our websites. Last week, our server manager upgraded us to the latest version of Debian and in doing so, we lost the permissions that allowed the CMS to run properly. Unfortunately, the programmer who set it up for us is not contactable, and we can't locate any documentation on his configuration.

Two questions:

* If it's a proprietary CMS, do you have a support agreement that would allow you to contact someone from the vendor to answer this question? (Assuming that a.) by "proprietary" you meant you paid some vendor for the SW and it's still supported and b.) the vendor isn't this unreachable programmer.)

* Is there an installer that was used to load the software? If so, you should be able to find the code in it that created the directory structure and assigned the permissions.

Quote:

There's a lesson there, I think.

Yep.

Did this fellow make a backup before doing the upgrade? If so, perhaps you could read that or restore it onto another system and get the permissions that way. (If not, well, there's yet another lesson.

) If the application was dependent on ACLs, things will be more difficult. I'm not sure if a file-based backup will retain that information let alone restore it. I'm pretty sure that "dump" would, though, but does anyone still use "dump"?

Tip for the future: If your hardware configuration will allow it, locate your application(s) on a separate file system so that upgrades to the OS do not clobber application-related stuff. Unmount the application filesystem, perform the OS upgrade, and remount the application file system.

Good luck.

--
Rick

sundialsvcs · 12-29-2009, 09:10 PM

Also bear in mind that most Linuxes these days support access control lists (ACLs) in addition to (thus, in effect, "in lieu of") standard Unix permissions.

Although Linux ACLs are not entirely the same in their implementation as is, say, Microsoft Windows' version of the same thing, the underlying principles are the same. Where ACLs hold court, Unix permission-masks mean nothing.

Anyhow, the first step in resolving issues like these is to fully understand them. The factors that are actually in play might not at first be obvious.

chestertb · 12-30-2009, 07:55 AM

Thanks Rick,
By "proprietary", I mean "we wrote it ourselves because we needed a degree of integration and functionality that an off the shelf CMS could never dream of".
Which means no... there's no support because we're it, and no, there's no installer because we built it in situ.
And no, sadly, there's no back-up. We backed up the data, but didn't see a need to back up anything else because previous upgrades haven't created this sort of problem. (One learns something new every day, it seems.)

Sundial, where am I likely to find the ACL, if it exists?

Cheers
CTB

rnturn · 12-30-2009, 11:22 AM

[QUOTE=chestertb;3808825]Thanks Rick,
By "proprietary", I mean "we wrote it ourselves because we needed a degree of integration and functionality that an off the shelf CMS could never dream of".
Which means no... there's no support because we're it, and no, there's no installer because we built it in situ.
And no, sadly, there's no back-up. We backed up the data, but didn't see a need to back up anything else because previous upgrades haven't created this sort of problem. (One learns something new every day, it seems.)[/quote}

Hope you're considering that dedicated application filesystem now. (I find them invaluable. Never understood the "make one gigantic filesystem for everything" mindset. Just considering tha amount of time needed for backup/restore makes me cringe.)

Quote:

Sundial, where am I likely to find the ACL, if it exists?

You could try

Code:

cd <app-tree-top>
find . -type d -exec getfacl {} \;

and see if anything shows up other than the permissions associated with the normal UNIX permission mask. Example: I created a subdirectory /tmp/tmpdir and another subdirectory, "subdir" in that. I changed the permissions of "subdir" to be "700". when I run "find tmpdir -type d -exec getfacl {}\;", I get:

Code:

# file: tmpdir
# owner: root
# group: root
user::rwx
group::r-x
other::r-x

# file: tmpdir/subdir
# owner: root
# group: root
user::rwx       <== "7"
group::---      <== "0"
other::---      <== "0"

Now I add a couple of access control entries (ACEs) to allow users in the "web" and "video" groups to be able to list the contents of subdir:

Code:

setfacl -m g:web:rx,g:video:rx subdir

Rerunning the find command, you'd now get

Code:

# file: tmpdir
# owner: root
# group: root
user::rwx
group::r-x
other::r-x

# file: tmpdir/subdir
# owner: root
# group: root
user::rwx
group::---
group:video:r-x
group:web:r-x
mask::r-x
other::---

Why would one want to do this? Well, for one, normally you can only allow a single group to have access. There may be times when you want to allow multiple groups to have access to an object and possibly have different types of permissions according the to group membership. You can define a default ACL to be assigned to new files created in the subdirectory. Pretty powerful stuff. The kink is that you have to be careful about how you assign users to groups, the order of the ACEs, and how you backup. If you're using ACLs you should probably consider making an ASCII dump of the ACLs prior to your daily backup and back up that dump along with the rest of the files.

Unfortunately, if you upgraded by wiping and reinstalling, there won't be any ACLs left to search for.

I suspect you're going to have to do a little code spelunking to find out what sort of access the application requires and make the needed changes to the various directories and files. A quick (and very dirty) fix would be to allow everyone to have read/write access the the entire application tree. Something that I would not -- no, make that NOT! -- recommend for obvious reasons but if your application is currently down and nobody can work you may have no choice. (I sincerely hope that this sort of access is not part of the application design but I have actually seen just that.) Do yourself a major favor by taking a complete backup of the application before making a change as radical as this. Or you could wait for your programmer to return. I'm afraid that this is probably not what you wanted to hear but there it is.

Personally, I'd dive into the code and figure out what permissions are needed. That way two people have to get hit by a bus before the application is unusable.

--
Rick