Discussion:
Permissions
Ethan Rosenberg
2013-08-27 04:29:35 UTC
Permalink
Dear List -

Tried to run the program, that we have been discussing, and received a
403 error.

rosenberg:/var/www# ls -la StoreInventory.php
-rwxrwxrw- 1 ethan ethan 4188 Aug 26 20:26 StoreInventory.php

rosenberg:/var# ls -ld www
drwxrwxrw- 37 ethan ethan 20480 Aug 26 20:26 www

I had set the S bit [probably a nasty mistake] and I thought I was able
to remove the bit. [it doesn't show above]

How do I extricate myself from the hole into which I have planted myself?

TIA

Ethan
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
David Robley
2013-08-27 06:46:18 UTC
Permalink
Post by Ethan Rosenberg
Dear List -
Tried to run the program, that we have been discussing, and received a
403 error.
rosenberg:/var/www# ls -la StoreInventory.php
-rwxrwxrw- 1 ethan ethan 4188 Aug 26 20:26 StoreInventory.php
rosenberg:/var# ls -ld www
drwxrwxrw- 37 ethan ethan 20480 Aug 26 20:26 www
I had set the S bit [probably a nasty mistake] and I thought I was able
to remove the bit. [it doesn't show above]
How do I extricate myself from the hole into which I have planted myself?
TIA
Ethan
This is in no way a php question, as the same result will happen no matter
what you ask apache to serve from that directory.

You have the directory permissions set to 776 not 777.
--
Cheers
David Robley

Steal this tagline and I'll tie-dye your cat!
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Ashley Sheridan
2013-08-27 06:59:25 UTC
Permalink
Post by David Robley
Post by Ethan Rosenberg
Dear List -
Tried to run the program, that we have been discussing, and received a
403 error.
rosenberg:/var/www# ls -la StoreInventory.php
-rwxrwxrw- 1 ethan ethan 4188 Aug 26 20:26 StoreInventory.php
rosenberg:/var# ls -ld www
drwxrwxrw- 37 ethan ethan 20480 Aug 26 20:26 www
I had set the S bit [probably a nasty mistake] and I thought I was able
to remove the bit. [it doesn't show above]
How do I extricate myself from the hole into which I have planted myself?
TIA
Ethan
This is in no way a php question, as the same result will happen no matter
what you ask apache to serve from that directory.
You have the directory permissions set to 776 not 777.
--
Cheers
David Robley
Steal this tagline and I'll tie-dye your cat!
776 won't matter in the case of a directory, as the last bit is for the
eXecute permissions, which aren't applicable to a directory. What

It's possible that this is an SELinux issue, which adds an extra layer
of permissions over files. To see what those permissions are, use the -Z
flag for ls. Also, check the SELinux logs (assuming that it's running
and it is causing a problem) to see if it brings up anything. It's
typically found on RedHat-based distros.

Thanks,
Ash
http://www.ashleysheridan.co.uk
David Robley
2013-08-27 07:07:44 UTC
Permalink
Post by Ashley Sheridan
Post by David Robley
Post by Ethan Rosenberg
Dear List -
Tried to run the program, that we have been discussing, and received a
403 error.
rosenberg:/var/www# ls -la StoreInventory.php
-rwxrwxrw- 1 ethan ethan 4188 Aug 26 20:26 StoreInventory.php
rosenberg:/var# ls -ld www
drwxrwxrw- 37 ethan ethan 20480 Aug 26 20:26 www
I had set the S bit [probably a nasty mistake] and I thought I was able
to remove the bit. [it doesn't show above]
How do I extricate myself from the hole into which I have planted myself?
TIA
Ethan
This is in no way a php question, as the same result will happen no
matter what you ask apache to serve from that directory.
You have the directory permissions set to 776 not 777.
--
Cheers
David Robley
Steal this tagline and I'll tie-dye your cat!
776 won't matter in the case of a directory, as the last bit is for the
eXecute permissions, which aren't applicable to a directory. What
I beg to differ here. If the x bit isn't set on a directory, that will
prevent scanning of the directory; in this case apache will be prevented
from scanning the directory and will return a 403.
Post by Ashley Sheridan
It's possible that this is an SELinux issue, which adds an extra layer
of permissions over files. To see what those permissions are, use the -Z
flag for ls. Also, check the SELinux logs (assuming that it's running
and it is causing a problem) to see if it brings up anything. It's
typically found on RedHat-based distros.
Thanks,
Ash
http://www.ashleysheridan.co.uk
--
Cheers
David Robley

Artificial Intelligence is no match for natural stupidity.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Daniel Brown
2013-08-27 16:22:02 UTC
Permalink
Post by David Robley
I beg to differ here. If the x bit isn't set on a directory, that will
prevent scanning of the directory; in this case apache will be prevented
from scanning the directory and will return a 403.
Well, that's partially correct. If a directory is owned by
someone other than the current user (for example, root) and is 0776,
you can list the directory content from outside of the directory to
get a basic file listing. What you won't get by doing that, however,
is anything other than the file name and type, because the kernel is
forbidden from executing mtime, ctime, and owner/group queries on the
files. In addition, you won't be able to enter the directory (cd).

That said, if Ethan is running his Apache server as the user
'ethan' (which isn't mentioned) then it would be fine regardless.

As for the 's' notation, that's either a bitmask of 0400 or 0200,
which are for setuid and setgid, respectively.
--
</Daniel P. Brown>
Network Infrastructure Manager
http://www.php.net/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Ethan Rosenberg
2013-08-27 17:52:30 UTC
Permalink
Post by David Robley
Post by Ashley Sheridan
Post by David Robley
Post by Ethan Rosenberg
Dear List -
Tried to run the program, that we have been discussing, and received a
403 error.
rosenberg:/var/www# ls -la StoreInventory.php
-rwxrwxrw- 1 ethan ethan 4188 Aug 26 20:26 StoreInventory.php
rosenberg:/var# ls -ld www
drwxrwxrw- 37 ethan ethan 20480 Aug 26 20:26 www
I had set the S bit [probably a nasty mistake] and I thought I was able
to remove the bit. [it doesn't show above]
How do I extricate myself from the hole into which I have planted myself?
TIA
Ethan
This is in no way a php question, as the same result will happen no
matter what you ask apache to serve from that directory.
You have the directory permissions set to 776 not 777.
--
Cheers
David Robley
Steal this tagline and I'll tie-dye your cat!
776 won't matter in the case of a directory, as the last bit is for the
eXecute permissions, which aren't applicable to a directory. What
I beg to differ here. If the x bit isn't set on a directory, that will
prevent scanning of the directory; in this case apache will be prevented
from scanning the directory and will return a 403.
Post by Ashley Sheridan
It's possible that this is an SELinux issue, which adds an extra layer
of permissions over files. To see what those permissions are, use the -Z
flag for ls. Also, check the SELinux logs (assuming that it's running
and it is causing a problem) to see if it brings up anything. It's
typically found on RedHat-based distros.
Thanks,
Ash
http://www.ashleysheridan.co.uk
I checked with the -Z option

***@rosenberg:/var/www$ ls -lZ StoreInventory.php
-rwxrwsr-t 1 ethan ethan ? 4232 Aug 27 00:18 StoreInventory.php

Ethan

PS David-

I promise that I will not steal your tag line. My short hair American
tabby cat [Gingy Feline Rosenberg]is too nice to have anything done to her.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Ethan Rosenberg
2013-08-27 17:55:41 UTC
Permalink
Post by Ethan Rosenberg
Post by David Robley
Post by Ashley Sheridan
Post by David Robley
Post by Ethan Rosenberg
Dear List -
Tried to run the program, that we have been discussing, and received a
403 error.
rosenberg:/var/www# ls -la StoreInventory.php
-rwxrwxrw- 1 ethan ethan 4188 Aug 26 20:26 StoreInventory.php
rosenberg:/var# ls -ld www
drwxrwxrw- 37 ethan ethan 20480 Aug 26 20:26 www
I had set the S bit [probably a nasty mistake] and I thought I was able
to remove the bit. [it doesn't show above]
How do I extricate myself from the hole into which I have planted myself?
TIA
Ethan
This is in no way a php question, as the same result will happen no
matter what you ask apache to serve from that directory.
You have the directory permissions set to 776 not 777.
--
Cheers
David Robley
Steal this tagline and I'll tie-dye your cat!
776 won't matter in the case of a directory, as the last bit is for the
eXecute permissions, which aren't applicable to a directory. What
I beg to differ here. If the x bit isn't set on a directory, that will
prevent scanning of the directory; in this case apache will be prevented
from scanning the directory and will return a 403.
Post by Ashley Sheridan
It's possible that this is an SELinux issue, which adds an extra layer
of permissions over files. To see what those permissions are, use the -Z
flag for ls. Also, check the SELinux logs (assuming that it's running
and it is causing a problem) to see if it brings up anything. It's
typically found on RedHat-based distros.
Thanks,
Ash
http://www.ashleysheridan.co.uk
I checked with the -Z option
-rwxrwsr-t 1 ethan ethan ? 4232 Aug 27 00:18 StoreInventory.php
Ethan
PS David-
I promise that I will not steal your tag line. My short hair American
tabby cat [Gingy Feline Rosenberg]is too nice to have anything done to her.
This has really morphed into a Debian issue. I have sent it to the
Debian list. I will keep you informed.

Ethan
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Ethan Rosenberg
2013-08-27 21:44:39 UTC
Permalink
Post by Ethan Rosenberg
Dear List -
I apologize for this "needle in a haystack" but...
This was originally posted on the PHP list, but has changed into a
Debian question...
Tried to run the program, that we have been discussing,{on the PHP list}
and received a 403 error.
rosenberg:/var/www# ls -la StoreInventory.php
-rwxrwxrw- 1 ethan ethan 4188 Aug 26 20:26 StoreInventory.php
rosenberg:/var# ls -ld www
drwxrwxrw- 37 ethan ethan 20480 Aug 26 20:26 www
I had set the S bit [probably a nasty mistake] and I thought I was able
to remove the bit. [it doesn't show above]
I made the following stupid mistakes...
note commands from the root prompt have a su appended
467 chown -R ethan:www-data www su
469 chown -R ethan:www-data www su
470 chmod -R g+s www su
471 chgrp -R www su
477 chgrp -R ethan www su
480 chmod -R 766 www su
482 chmod g-S www su
485 chmod -S www su
486 chmod g S www su
487 chmod gS www su
488 chmod S www su
489 chmod 776 www su
492 chmod 776 -R www su
494 chmod -s -R www su
504 chmod 666 StoreInventory.php
512 chmod 3775 StoreInventory.php
I now have....
-rwxrwsr-t 1 ethan ethan 4232 Aug 27 00:18 StoreInventory.php
drwxrwxrw- 37 ethan ethan 20480 Aug 26 20:26 www
and still have the 403 error.
How do I extricate myself from the hole into which I have planted myself?
The problem appears to be that Apache does not have access to the file.
Looking at the permissions of the file it should work, however, apache
is not able to go into your /var/www folder. Either you need to set
www-data as the owner of the directory, or as the group owner, or,
possibility number 3, give execute rights to 'others' on that folder.
1) chown www-data /var/www
2) chgrp www-data /var/www
3) chmod -R o+X /var/www
Note the capital 'X' on option 3, this gives execute permissions on
folders only, not files, as the -R means all files and subdirectories as
well.
The 't' is known as the sticky bit if I recall correctly, set with 1 on
the first number in a 4 number chmod command, for details see [1].
I guess in your case you can use 0664 for the files and 0775 for
directories (or 0640 and 0750 if you set owner or group back to
www-data)
Best regards,
Steven
you wrote about a 403 error, so I assume you invoke the script by
calling a webserver via browser.
In that case the webserver needs the permission to access /var/www and
to read StoreInventory.php.

By default the webserver runs as user/group www-data (it can be changed
in the webservers config-file(s)).

Try this:

#chown -R ethan:www-data /var/www
#chmod 775 /var/www
#chmod 640 /var/www/StoreInventory.php

Your ls should return something like this:

$ls -hal /var/www
drwxr-x--- 1 ethan www-data 4.0K Jun 3 20:35 .
-rw-r----- 1 ethan www-data 623 Jun 3 20:35 StoreInventory.php


If that does not work you might check the configuration- and log-files
of your webserver.

Dear List -

I had to go to a meeting but before I left I tried one last thing -

chmod 000 www
chmod 0777 www
rosenberg:/var# ls -ld www
drwxrwxrwx 37 ethan ethan 20480 Aug 27 17:30 www

chown ethan StoreInventory.php
chgrp ethan StoreInventory.php
chmod 000 StoreInventory.php
chmod 777 StoreInventory.php
***@rosenberg:/var/www$ ls -la StoreInventory.php
-rwxrwxrwx 1 ethan ethan 4232 Aug 27 17:25 StoreInventory.php

when I returned...

IT WORKS!!!

Thanks to all.

Ethan

Loading...