Just read about using the 707 folder permission in place of 777. Does anyone know if XOOPS and/or modules would install and work with this permission, or if there are any real advantages to using it on a shared server?

Actually, 707 would not offer any benefits.

first number = Owner
second number = Group (the owning group)
third number = Others (the world)

707 would allow full permissions to the owner and the world, but no permisions to the owning group.

Thx JMorris. I have always obliged and changed folder permissions as requested when installing PHP apps. But I confess I don't really understand it that well.

I grasp the 'owner' status. Although I'm not sure how how a web server identifies a file or folder owner - by IP address? I can also see the 'others' privilege is required to allow anyone (users of a CMS like Xoops) to upload avatars etc.

I just have never really understood who is in the default 'group' if none is specifically created. Got the impression it might be anyone else using the same server. Which is why I thought the 707 setting might be more secure.

Need to do more homework.

Actually, the ownership structure in *NIX (the chown settings) has little to do with you or your visitors. Perhaps this will clear things up for you a bit...

By default, when you install apache web server, it creates a user account "apache" and a group "apache". Every file placed in the web root (/var/www/html by default) is either owned by the "apache" or the "root" user and group. The only way this changes is if the Administrator of the webserver (root user) changes the ownership of the files and directories with the chown command.

For example, on shared hosting, and Admin may wish to have several directories under /var/www/html for the purposes of shared hosting. These directories may be named /u123, /u456, /u789, etc. The Admin may then change the ownership of each directory to match its respective hosting account. This is useful for auditing, but does not change how the sites are accessed from the web.

The ownership of the file or folder has little to do with who has access to them from the web. Access to is granted/denied through chmod. The Admin can accept the default permissions for the file and/or folder (chmod), or choose to set explicit permissions, or redefine the default permissions (umask) [this is preferred].

For example, my web host has set a umask (default chmod setting) of 755 for directories and a 644 for files, which is perfect for XOOPS.

### I know this is getting long winded; I'm getting there ###

The numerical values indicate read (open), write (change), and execute (run or traverse directory).

4 = read
5 = read & execute
6 = read & write
7 = read, write, & execute

These permissions are set on a Owner - Group - Other (everyone) basis. Therefore....

755 means The owner can read, write, and execute. The owning group and everyone else can read and execute.

While...

644 means The owner can read and write. The owning group and everyone else can just read.

The ownership part comes in when you either FTP or ssh into your account to upload/edit files. If your hosting account was setup with 444 or 555, you wouldn't be able to upload or edit files.

The reason that the Owner and Group settings are not necessarily the same is that an Admin may combine several users into one group (take "ftpusers" as an example). By specifying the permissions to set files and folders as writable ONLY by the Owner, no other group member can make changes.

A good rule of thumb: Give group the same permissions as others (everyone else). ONLY give write permission to the Owner.

All of the above can be a little confusing when you're talking folders rather than files. Just remember that it's good practice to set your folders to a minimum of 755. I've actually locked myself out of a site because I didn't set the folders as executable. Go figure.

Well, I hope this helped. I highly recommend Google'ing chmod, umask and chown. Whether you plan to use/admin a *NIX box or not, having a basic understanding of how permissions are set can really help you troubleshoot problems and lock down the security of your site. Besides, I'm human, there may be a mistake or two in what I said.

Best Regards!

I am going to read all of that... slowly... and when I have had less to drink! Thx for such a detailed reply.

Permissions are a make or break thing for XOOPS and it's modules, so perhaps you should write this in the FAQ? Be good to see the IIS equivalents too, 'cos I see a lot of posts from people who have problems with installing XOOPS on Windows.

I did a little digging today and found a small simulator that helps explain how the permissions are set using graphical forms like you get in CPanel etc. It's at:

http://www.ss64.com/bash/chmod.html

The form is about half way down the page. You can tick the boxes for 'owner', 'group' and 'other' and you get the appropriate numeric values underneath. E.g.

...........Owner .........Group .........Other

read.......X..................X...............X

write......X..................0................0

exec......X..................X................X

.............7..................5................5

My tip to help remember how they add up is:

The read row is all 4's

The write row is all 2's

The exec row is all 1's

Disclaimer: This tip was brought to you by a man who needed a coloured-blocks learning aid to get him through maths in junior school.

I have a new permissions query.

I had a bright idea to get shell access from my host so I could create a TAR archive of an entire directory, upload it and decompress it in-situ.

I got Gnu TAR for Windows which I run under Win 98. Everything works fine, it creates the TAR file o.k, but I hit a problem when I decompressed the file on a Linux server. All the files *and* folders wound up with the permission of 666!

I created the TAR with the command

tar --create --file=myfile.tar *.*

But, I used the command

tar xvfp myfile.tar

to decompress it, which is where I guess I goofed. I *think* I should have just used:

tar xvf myfile.tar

without the 'P' for retaining permissions.

Can anyone tell me if this command will use the server's default file and folder permissions when the file is extracted.?

I don't want to repeat the same error. It took me over an hour to delete the application because of course I had to CHMOD every nested folder manually to delete it!

The p option retains the original file permissions (ie: what they were on the computer you created the archive on). I would not use this option. Instead, when extracting, just use tar xvf filename.tar. Alternately, zip and unzip are supported on *NIX as well.

To zip a file on *NIX:
zip target_filename.zip target_file

To unzip a file on *NIX:
unzip target_filename.zip

The 666 permission is equivalent to read/write for owner, group and world (other). This would be the default permission for a Windows file, which makes sense.

Hope this helps.

Thx JMorris. I'll try again. But thanks for letting me know that ZIP is supported. Actually, that's very good news as a TAR archive alone is actually bigger than the total folder sizes.

Out of interest, do you (or anyone) know a good app that creates TAR.gz on Windows?.

As a follow on from the original thread, my host doesn't allow CHMOD 707 for folders. I get a permission denied error. Only 777 seems to work.

You may want to look at Filzip. I believe it can create tgz archives.

I tried Filzip. It created the tar.gz, but when I came to decompress it online I got an error message like:

file contains obsolete base 64 headers?

or something similar (I confess I didn't write it down - totally fed up with it by then).

My mood didn't improve when I re-uploaded the original TAR file and decompressed it using just xvf - and this time all the files/folders wound up with the permission of 664! Not much better than last time.

I have yet to try Zip. But, if anyone is successfully creating tar.gz files on Windows and decompressing them on a Linux server with the correct permissions, (folders 775, files 644) I would love to know their secret!