Default permissions for new files/directories

R

rmomota

Hi all!
I did look for several posts before deciding to post this one.
This topic is important as is regarding to file system and data access security.
All I want to do is to be able to protect all my files, in my home at least, with something like 750 by default, meaning:
Owner: Read (Files and Directories), Write (Files and Directories) and Execute (Files and Directories)
Group: Read (Files and Directories) and Execute (Directories only)
Other: Go away!!!

I read about using the umask entry in ~/.login_conf so I added something like:
me:\
:umask=027:

and executed
$ cap_mkdb ~/.login_conf

Log off and login again and executed
$ touch test
and the file got like
-rw-r--r--
instead of
-rw-r-----

the created a test_dir and it got this
drwxr-xr-x
instead of
drwxr-x---

Seems the umask isn't working at all.

What's the best way to grant these privileges?
Thank you.
 
I just have umask xxx in my .zshrc -- it starts like this:

umask xxx # replace xxx with the mask you want
if [[ ! -o interactive ]] ; then return; fi
 
Seems to work but what happens when you have a process that you started and it creates files?
example when you "git clone" a project.
 
It does not work when I created a file in XFCE application line Thunar, so I believe that any other tool will be the same.
Git may work because it was launched from the terminal.
I would like to have a better solution than this umask in shell startup scripts
 
Put it in your login shell's login script -- .zlogin or .login or .bash_profile or whatever. But that won't prevent any new process from setting its umask.

If you are using a shared machine this matters some but in that case just chmod your home dir to 700. On your personal machine it matters much less unless you are giving accounts to other people (which you shouldn't, unless you trust these people).
 
I did put it in .cshrc
In fact there's a comment there for that
(...)
# These are normally set through /etc/login.conf. You may override them here
# if wanted.
# set path = (/sbin /bin /usr/sbin /usr/bin /usr/local/sbin /usr/local/bin $HOME/bin)
# A righteous umask
# umask 22
(...)

so this seems to be the most correct script for it to be.
So the fact here is that ~/.login_conf is not working contradicting the documentation

Thank you!
 
A: What are you trying to protect against? Other users of the same machine, who are not root? That is really the only use case for permissions. The permission bits do not protect against root. Nor against hackers who have the ability to become root. Nor against people who can take control of your hardware (like physically take your laptop).

B: The umask that is set during login or from the shell is only the default for files that are created without performing any changes to permissions. A running process has the ability to create files with arbitrary permissions, and to change the permissions of existing files (including ones it has created) within the confines of existing permissions. And it turns out a lot of file-management programs (such as tar) do that very explicitly, when they try to restore permissions of existing files. I don't know what git specifically does here, but I would expect that if you do a "git clone", it will honor some of the existing permissions of files it creates; for example, it needs to set the x bit when creating scripts.

C: You say that ~/.login_conf is not working. There is a very easy and direct way to test that, much more reliable than creating files: Set your umask there, then login. In that shell, say umask. Does it report the value you have set?
 
You can find best practices for default permissions and a lot of other stuff at Center for Internet Security. FreeBSD isn't currently listed but the FreeBSD Foundation announced last week at the developer summit that it is on their todo list to have FreeBSD best practices listed at CIS.
 
ralphbsz said:
A: What are you trying to protect against? Other users of the same machine, who are not root? That is really the only use case for permissions. The permission bits do not protect against root. Nor against hackers who have the ability to become root. Nor against people who can take control of your hardware (like physically take your laptop).

B: The umask that is set during login or from the shell is only the default for files that are created without performing any changes to permissions. A running process has the ability to create files with arbitrary permissions, and to change the permissions of existing files (including ones it has created) within the confines of existing permissions. And it turns out a lot of file-management programs (such as tar) do that very explicitly, when they try to restore permissions of existing files. I don't know what git specifically does here, but I would expect that if you do a "git clone", it will honor some of the existing permissions of files it creates; for example, it needs to set the x bit when creating scripts.

C: You say that ~/.login_conf is not working. There is a very easy and direct way to test that, much more reliable than creating files: Set your umask there, then login. In that shell, say umask. Does it report the value you have set?
Click to expand...
I want to protect my files from non root users/processes.
Of course this is useless for hackers who have the ability of becoming root but for that they would have to get trough several protection layers like network and running services, even the SSH daemon is OFF by default, unless FreeBSD has a backdoor, does it?
Now you got me worried.
Well, with the entry in .cshrc it worked, the touch file shows the correct permissions what I wanted to achieve.
The .login_conf didn't, so it's a good test.
 
You must log in or register to reply here.
Back
Top