[SOLVED] default permissions for a www folder

Yam-Joyous · 08-18-2010, 08:33 AM

I'm trying to figure out how to get default permissions setup for a non shell account.

I've tried umask but it only seems to apply to my main account (shell?) and I would like to apply it to an ftp account I created. I installed and configured vsftp and played in the config file (chown_uploads=NO
chown_username=ftp-user) are not commented and this assignes the right group and user but the files have the wrong permissions for a group project -rw-r--r-- I need the members of my group to be able to also edit the files -rwxrwxr-x (775)?

I tried changing the folder options to -rwxrwsr-x but again this seems to apply to my account and not the ftp-user account.

Then I read this thread which seems to contain a solution to my answer but I get syntax errors when I try this :

Quote:

Originally Posted by nikaudio

if [ $UID -eq 502 ]; then
umask 002
fi

# id glassd
uid=502(glassd) gid=502(glassd)

Is there a way to set up umask to 0002 for nologin account ?

Slawomir

My syntax error in shell:

Code:

bash: /home/myUserAccount/.bashrc: line 17: syntax error near unexpected token `('
bash: /home/myUserAccount/.bashrc: line 17: `uid=503(ftp-user) gid=501(www-group)'

What is the language or scripting language used in bash files so I can go and read on syntax?

Is this the appropirate approche to my problem? I tried assigning default permissions for the folder with chmod -R 775

Read and tried to understand on file permissions in Linux
Read and tried to understand users and groups
umask / chmod / chown but these don't work, I have to chown and chmod everytime a user uploads files for a website!

Yam-Joyous · 08-18-2010, 09:36 AM

Ok none of the things I tried seem to work so I went back and looked at the vsftpd.conf file and Googled for help on this file. Turns out there's an option in configuration that was not set correctly, no matter what I did in the OS the config file was overridding my commands!:

# Default umask for local users is 077. You may wish to change this to 022,
# if your users expect that (022 is used by most other ftpd's)
local_umask=002

Now I just have to understand the default values and how to set my umask in the ftp server to get my values to -rwxrwxr-x...

Mr. C. · 08-18-2010, 10:17 AM

The FTP server software determines the file permissions of uploaded files. The umask value is available to such applications, and by default will be used when creating new files, but security-aware applications manage this themselves.

Use vsftpd's constructs for setting upload file permissions.

Yam-Joyous · 08-18-2010, 01:41 PM

The default system setting are too restrictive and applying a umask doesn't help. umask doesn't help from system or from vsftpd.conf because the defaults are all locked (default file values are -wr-------). I would change the defaults but I don't know where to do this or how. Even if I knew it wouldn't be a good idea security wise to assign low restrictions to ftp user accounts.

I want to be able to overide the system settings for the public_html folders ONLY. The ftp-user account is not a shell account. I've tried all the settings in the vsftp.conf file, read the user guide but to no avail. All ftp uploads are inaccessible and chmod after every client upload is not a solution.

jay73 · 08-18-2010, 02:51 PM

Can't you just use ACLs on that folder? They are a lot more flexible than applying a umask.

Mr. C. · 08-18-2010, 02:53 PM

Exactly, it is not a good idea to reduce restrictions. It creates real DoS security issues.

Ignore umask - it is not relevant here.

All that you want can be accomplished with vsftpd's configuration parameters. How you accomplish this depends on what you want to allow of your users whose public_html directories will be uploaded. Do these users have shell accounts? Are they to be trusted?

If you want users to be able to upload to their public_html folders, you probably don't want the ftp-user account. You'll want either virtual or real user accounts.

Perhaps it would be better to describe our needs completely.

There are plenty of HowTo's, etc. on how to configure vsftpd for various situations.

Most importantly, for anyone setting up an ftp server, is to learn about how each setting affects an ftp login, and security. Don't skimp here.

Yam-Joyous · 08-19-2010, 02:49 PM

I got a bit done yesterday with the ACLs but I am still having trouble as my files are missing the execute bit on creation. I have the proper username and group assignments but that last x won't show. I can't figure out if I have done something else in the past that is now hindering my efforts at the ACL level. Sticky bit?

Code:

getfacl public_html/
# file: public_html/
# owner: ftp-user
# group: www-group
# flags: -s-
user::rwx
group::rwx
other::r-x
default:user::rwx
default:user:ftp-user:rwx
default:group::rwx
default:group:www-group:rwx
default:mask::rwx
default:other::r-x

Here's inside the folder:

Code:

[root@fedora13 public_html]# ls -l
total 12
-rwxrwxr-x. 1 ftp-user    www-group 1344 Aug 18 22:53 index.php
-rw-rw-r--+ 1 root        www-group    0 Aug 19 15:24 test2.txt
-rw-rw-r--+ 1 root        www-group    0 Aug 19 15:29 test3.txt
-rw-rw-r-x+ 1 myLogin     www-group    0 Aug 19 15:23 test.txt
-rw-rw-r--+ 1 ftp-user    www-group  316 Aug 19 15:37 untitled0.php
-rw-rw-r--+ 1 ftp-user    www-group  316 Aug 19 15:01 untitled.php

getfacl for newly created file:

Code:

[root@fedora13 public_html]# getfacl untitled.php 
# file: untitled.php
# owner: ftp-user
# group: www-group
user::rw-
user:ftp-user:rwx		#effective:rw-
group::rwx			#effective:rw-
group:www-group:rwx		#effective:rw-
mask::rw-
other::r--

I read on another page where someone suggests -r to reset or reread the ACLs but can't figure out the sintax for that and where I should apply it.

I'm going to try removing the sticky bit and see if that helps. I removed Samba shares from /srv/www/domain/public_html

To answer questions about do I trust users? No catagorically. It's bad enough I screw things up, I'm not going to add other users into the mix!

P.S.: This whole project is to teach myself about Linux/administration/configuration but my main purpose in life is to learn to code and become a developper. But I'm the type of person who when he sits behind the wheel of a car, needs to understand how things under the hood work. What if I break down in the middle of no where and need to fix it to survive? Same thing with computers, I need to understand what is going on or I don't feel comfortable sitting behind the keyboard!

Thanks for all the help so far....

Yam-Joyous · 08-19-2010, 03:15 PM

I removed the stickbit chmod -t -s
I removed the ACLs setfacl -b public_html
Now when I create a file it has these permissions:
-rw------- 1 ftp-user www-group 316 Aug 19 16:09 untitled2.php

I don't know what to try, I'll go see if I can find the howto on -r option something about rereading the acls or resetting...

jay73 · 08-20-2010, 04:08 AM

It is simply not possible to create files with default execute permissions. On most systems, default directory permissions = 755; default file permissions = 644. Using the umask command, you can elevate 755 to 777 and 644 to 666; but you won't be able to elevate 666 to 777. It's a security measure and unless I'm mistaken it is actually built into the kernel so you'd have to edit and recompile the kernel source to bend it the way you like. There is reason for those restrictions, though, so you'd better not.

Mr. C. · 08-20-2010, 09:12 PM

What a curious thing to say.

Code:

$ ls -l
total 4
-rw-r--r-- 1 mrc mrc 78 2010-08-20 19:05 test.c
$ cat test.c
#include <fcntl.h>

main() {
	umask (000);
	open("./afile", O_CREAT, 0777);
}
$ gcc test.c
$ ./a.out
$ ls -l
total 16
-rwxrwxrwx 1 mrc mrc    0 2010-08-20 19:10 afile
-rwxr-xr-x 1 mrc mrc 9185 2010-08-20 19:10 a.out
-rw-r--r-- 1 mrc mrc   78 2010-08-20 19:05 test.c
$uname -a
Linux ubuntu 2.6.28-11-server #42-Ubuntu SMP Fri Apr 17 02:48:10 UTC 2009 i686 GNU/Linux

sag47 · 08-20-2010, 09:21 PM

Quote:

Originally Posted by jay73

It is simply not possible to create files with default execute permissions. On most systems, default directory permissions = 755; default file permissions = 644. Using the umask command, you can elevate 755 to 777 and 644 to 666; but you won't be able to elevate 666 to 777. It's a security measure and unless I'm mistaken it is actually built into the kernel so you'd have to edit and recompile the kernel source to bend it the way you like. There is reason for those restrictions, though, so you'd better not.

I disagree, it depends on the limitations of the software/server.

proftpd can do this using their umask directive located within proftpd.conf. I have a software server setup with this very directive in mind on a corporate intranet.

You just have to read the docs for vsftp and see if they provide a like option.

I agree with Mr. C.: "Don't skimp here."

It is always a good idea, when dealing with user uploads, to umask them as 027. That way the permissions are private away from the public by default and the user can change them later if they wish.

SAM

jay73 · 08-20-2010, 10:02 PM

Well, I guess I may indeed have been skimping. Then again, I'm not sure what to make of that C code. That would illustrate the case of a user explicitly/manually granting execute permission, which is different from execute permission assigned as a default at file creation time. I never said it can't be done that way.
Just open a terminal and enter:
umask 000
create a directory and it will be 777
enter that directory and create a file: it will be 666, in spite of the 000 mask.

I may well be mistaken about it being a kernel feature. Then again, I wouldn't know where it is set (it may just as well be compiled into the shell, though, I don't know). I know that grepping /etc for any umask that specifically governs file creation didn't produce anything useful.

Mr. C. · 08-20-2010, 10:56 PM

The kernel allows files to be created with whatever permissions are requested by the program creating the file. The code was a demonstration of this.

By *default*, files and directories are created with full permissions (i.e. 666 and 777) minus the permissions negated with the umask value. This occurs when the program creating the file / directory does not set an explicit mode in an open(2) or creat(2) system call.

Generally it does not make sense to create files with execute permissions, so programs don't do this. But there is no reason why they can't (again, see above program). A compiler, for example, creates an executable a.out file when it is completed. Whether this is done by creating an executable a.out file, or by simply creating a file, and then setting explicit permissions via chmod(2) is left as an exercise for curious readers (hint: man truss or man strace).

Well written programs always set explicit file modes when they create files, so as not to create unexpected results.

Yam-Joyous · 08-24-2010, 02:19 PM

Ok I'm officially confused! I removed (commented out) umask in vsftpd.conf, I reset (removed) sticky bit from my folder and reset ACLs to default.

I set umask in console to 000
Login via FTP from another computer and create a file and folder and I get:

drwx------ 2 ftp-user www-group 4096 Aug 24 15:11 untitled
-rw------- 1 ftp-user www-group 316 Aug 24 15:09 untitled.php

With umask set to 000 shouldn't my permissions be less restrictive?
This is 700 for folder and 600 for file! What am I not getting here?

Mr. C. · 08-24-2010, 03:07 PM

No, no, no! ;-)

The process' (vsftpd) umask setting, as I mentioned, is *ignored* by vsftpd, because vsftpd *always* controls file permissions using the settings from the vsftpd.conf file.. It does not leave such settings to external control such as the umask shell built-in (which calls umask(2) to set the process' umask value). This would require the system admin to configure various shell startup configuration files, and is not as flexible. Again, vsftpd controls its own permissions.

umask is simple inherited by a process, but a parent process cannot (repeat, cannot!) force a child to retain or even use this value.

Best to show your vsftpd.conf (and other vsftpd related) configuration files.