LinuxQuestions.org
Latest LQ Deal: Linux Power User Bundle
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Newbie
User Name
Password
Linux - Newbie This Linux forum is for members that are new to Linux.
Just starting out and have a question? If it is not in the man pages or the how-to's this is the place!

Notices


Reply
  Search this Thread
Old 12-20-2009, 07:54 PM   #1
chestertb
LQ Newbie
 
Registered: Dec 2009
Posts: 3

Rep: Reputation: 0
Comfiguring Complex Permissions


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
 
Old 12-21-2009, 04:11 PM   #2
harry edwards
Member
 
Registered: Nov 2007
Location: Lincolnshire, UK
Distribution: CentOS, Fedora, and Suse
Posts: 365

Rep: Reputation: 48
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.
 
Old 12-26-2009, 09:22 PM   #3
chestertb
LQ Newbie
 
Registered: Dec 2009
Posts: 3

Original Poster
Rep: Reputation: 0
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.
 
Old 12-29-2009, 07:16 PM   #4
rnturn
Senior Member
 
Registered: Jan 2003
Location: Illinois (Chicago area)
Distribution: Red Hat (8.0, RHEL5,6), CentOS, SuSE (10.x, 11.x, 12.2, 13.2), Solaris (8-10), Tru64, MacOS, Raspian
Posts: 1,108

Rep: Reputation: 64
Quote:
Originally Posted by chestertb View Post
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
 
Old 12-29-2009, 10:10 PM   #5
sundialsvcs
LQ Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 7,162

Rep: Reputation: 2205Reputation: 2205Reputation: 2205Reputation: 2205Reputation: 2205Reputation: 2205Reputation: 2205Reputation: 2205Reputation: 2205Reputation: 2205Reputation: 2205
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.
 
Old 12-30-2009, 08:55 AM   #6
chestertb
LQ Newbie
 
Registered: Dec 2009
Posts: 3

Original Poster
Rep: Reputation: 0
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
 
Old 12-30-2009, 12:22 PM   #7
rnturn
Senior Member
 
Registered: Jan 2003
Location: Illinois (Chicago area)
Distribution: Red Hat (8.0, RHEL5,6), CentOS, SuSE (10.x, 11.x, 12.2, 13.2), Solaris (8-10), Tru64, MacOS, Raspian
Posts: 1,108

Rep: Reputation: 64
[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
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
complex password sachin1361 Linux - Enterprise 2 04-01-2008 03:46 AM
Debian Way to a complex xinitrc? mpapet Debian 1 11-17-2007 07:59 PM
complex shape modeling rhb327 Linux - Software 0 02-11-2006 07:46 AM
gsl_complex vs <complex> darknails Programming 0 02-27-2005 11:24 AM
Rather complex NFS install kleptophobiac Slackware 5 07-30-2003 10:00 AM


All times are GMT -5. The time now is 08:15 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration