To start out, let me show you an excerpt of a ls -la in my /var/www/html:
drwxrwxr-x+ root root ./
drwxr-xr-x root root ../
drwxrwx---+ apache licenseGrp encrypt/

I believe that the bottom line is that the (+) in my permissions is causing some really strange things to happen. Everywhere else on my machine (such as one level up in /var/www,) the (+) is absent, and things run as expected: everyone can read, but only root can write to the directory.

I could assume this is some sort of 'feature' in linux: Right now, everyone can write to /var/www/html even though that no one (spare 'root') should. It hasn't bothered me in the past, mostly because I didn't care. However, I need to get this figured out for many reasons (security mainly,) but also because:

I have a user 'license' which is the only authorized user on my system to create software licenses. I have a webpage set up where an authorized user can input license information, and in turn will run (EDIT:) `sudo -u license /home/license/encrypt`. (/EDIT) In theory, this 'encrypt' script will grab an unencrypted license file in /var/www/html/encrypt, encrypt it, and then overwrite it to that same directory. The problem is, user 'license' CANNOT write to that directory, even though it is part of webadminGrp! Not only that, but it cannot write to ANY directory in /var/www/html! On the other hand, I (user 'evlach') am also part of licenseGrp, and CAN write to the directory, as well as /var/www/html.

I could go on with the abnormalities, but I'll leave you with that to ponder. Does anyone have ANY insight as to what could be the ding-dong-deal?

Thanks -Eric

I am running RedHet EL4, with SElinux enabled.

man pages

For instance, I think you wanted "-u" instead. The way you invoke it, sudo will just print a usage message to stderr, because you pass extra arguments beyond -l (namely, "license" and "/home/license/encrypt").

It won't do anything, and, as you observe correctly, not attempt writing into that directory with spaces in its name.

Maybe ls will explain under what circumstances it prints "+".

/Quigi

The plus sign indicates that there is an ACL associated with the file. Found it while searching the net

guessing the selinux has something to do with it. since thats the only acl that i know of with rhel4

do a ls -lasZ and post the results so we can see the selinux permissions

getfacl = view extended ACL's

Gosh, that was my typo... I do have -u in there, of course!

Slimm609 - here is ls -laZ:

drwxrwxr-x+ root root system_u:object_r:httpd_sys_content_t ./
drwxr-xr-x root root system_u:object_r:httpd_sys_content_t ../
drwxrwx---+ apache licenseGrp root:object_r:httpd_sys_content_t encrypt/

The rest of my directories are either user_u:object_r:httpd_sys_content_t or root:object_r:httpd_sys_content_t. I'm not quite sure what that means, I'll be looking into it.

My google-fu wasn't up to snuff, thanks for finding out about that access control list!

jeenam- here is getfacl of encrypt/:

# file: encrypt
# owner: apache
# group: licenseGrp
user::rwx
group::r-x
group:webadminGrp:rwx
mask::rwx
other::---
default:user::rwx
default:group::r-x
default:group:webadminGrp:rwx
default:mask::rwx
default:other::r-x

Theres a lot of stuff in there that I don't understand yet, I have a lot of researching to do. But all of this is putting me on the right track, thanks. If you have any more thoughts/hints, I'm all ears. I'll get to work on this and report back.

sorry i forgot to have you do a sestatus

also look in /etc/selinux/policies/ (or something close to that) and look at the httpd policy for selinux. If you want to test to see if it is selinux the fast way. edit /etc/selinux/config to say disabled instead of enabled and then reboot. That will disable selinux for a short time to test it. If it is not firewalled or sitting behind a firewall i would disconnect the network cable for that test just to be safer.

In case you didn't know but might need it:

http://www.suse.de/~agruen/acl/linux-acls/online/