Changing umask isn't taking effect

O

objecttothis

I'm using csh.
After running lynis I decided to try out an umask of 027, but then decided that it was too much work to manage permissions of new files and folders in the webserver root, so I changed it back to 022, but new directories are still being created with 750 and files with 640 permissions.

I checked .cshrc and umask is commented out there.
in /etc/login.conf I have
Code: 
:unmask=022:\
What am I missing here? Aside from saving the file, is there anything else I need to do to successfully change the unmask?
 
Last edited by a moderator:
Way too little detail to help debug. You said "decided to try out" ... what did you really do? Did you type the umask command once from the command line? Did you edit a setup file? If yes which one? Did you restart the shell (more or less like log out and back in) after changing the setup file? What is the umask right now? You can check it by using the command "umask" with no arguments. What happens if you create a file and/or directory right now?
 
Sorry, this is what I get for working on this at 3:15am. Yes, umask. I'm also trying to learn how to harden the server as I go. Go easy on me.

I ran lynis which reported umask at 022 then suggested changing it to 027. I then edited /etc/login.conf then restarted the jail. The changes took effect as I reported above. New directories were getting 750 permissions and new files 640.

To revert the changes I edited the same file and returned umask back to 022 (:umask=022:\). I saved and closed the file then restarted the jail again. The changes did not take effect. I then looked at .cshrc in my home directory to make sure umask wasn't being overridden there. It is not. I can run the umask command from the command line and get 027. If I run umask 022, it changes the umask to 022, but when I logout then log back in that change is reverted. I don't know where to look besides .cshrc in the home directory and /etc/login.conf to see what is overwriting this umask directive. I don't remember needing to make any change to set umask to 027 besides editing /etc/login.conf.
 
OK, you're saying that the current state is:
  • You are newly logging in (not starting a subshell).
  • /etc/login.conf has umask=022
  • You are using csh, not sh.
  • ~/.cshrc does not modify umask, and there are no other setup files that do, nor does .cshrc (or other setup files) execute other scripts. By "other setup files" I mean for example /etc/csh.cshrc and csh.login, and ~/.login. To see what files (t)csh will execute, read "man csh".
  • Yet you end up having umask set to 027 in the shell.
That combination unfortunately makes very little sense. One of the above assumptions must be wrong.

The one thing I'm uncertain about: You're using a jail. I haven't done jails, and don't know whether the jail has its own copy of /etc/login.conf and the various setup files. I worry that you the files you are looking at are not the ones that the jail really uses.
 
objecttothis said:
I then edited /etc/login.conf then restarted the jail. The changes took effect as I reported above.
Click to expand...
objecttothis said:
To revert the changes I edited the same file and returned umask back to 022 :)umask=022:\). I saved and closed the file then restarted the jail again.
Click to expand...
objecttothis said:
I don't remember needing to make any change to set umask to 027 besides editing /etc/login.conf.
Click to expand...
That's unlikely. Simply changing the umask(1) (or other attributes and capabilities) in the /etc/login.conf file hasn't an effect until run cap_mkdb(1) on it and log out, log in the user.

login.conf(5)
Rich (BB code): 
     The default /etc/login.conf shipped with FreeBSD is an out of the box
     configuration.  Whenever changes to this, or the user's ~/.login_conf,
     file are made, the modifications will not be picked up until cap_mkdb(1)
     is used to compile the file into a database.

Have you maybe run cap_mkdb(1) the first time but forgot the second time?
 
.cshrc has forever contained:

# A righteous umask
umask 22

If you messed with that, put it back ( or 27 if that's what you want, if you are well advised? )

Leave /etc/csh.cshrc alone, tho it should set umask 22 also.

Don't set umask in .login. Read man csh to understand why.

FreeBSD is not 'lynis'; ignore advice from there re FreeBSD.

If you're going to mess with important system files, at least keep copies of originals so you can undo any damage, e.g:

# cp -p .cshrc .cshrc.orig
 
OK, I think I'm closer to figuring out what is causing the problem. I ran grep -rl umask=027 and found it in /etc/login.conf.db which does not seem to be a file meant to be user edited and I never changed manually in the first place. I don't know how to regenerate this file as it seems to me that it's stale.

running grep against umask found /.cshrc, /home/[username]/.cshrc and /etc/login.conf
umask 22 is commented out by default in the first two. Uncommenting them overrides the 027 value that I think login.conf.db is setting globally. This fixes the problem for users as long as I set these for each user and each shell.

smithi I certainly don't have your experience with this, but if an admin is wanting globally set umask for all users, it makes more sense to me than setting it in the shell config files for each user.
 
Looks like T-Daemon called it. No I had neither run cap_mkdb(1) when initially changing umask, though it took effect anyway. Nor did I run it last time. I ran cap_mkdb /etc/login.conf and that resolved the issue.
 
objecttothis said:
OK, I think I'm closer to figuring out what is causing the problem. I ran grep -rl umask=027 and found it in /etc/login.conf.db which does not seem to be a file meant to be user edited and I never changed manually in the first place. I don't know how to regenerate this file as it seems to me that it's stale.
Click to expand...

FreeBSD has a manual page for every system file, in this case I suggest spending time with
login.conf(5).

Be aware that changes to the default: class affect root logins as well. This file is not usually used to set umask, and you'll see that 022 is the default there.

As the man says, the leading 0 is required in login.conf, but it is not on the command line, nor in .cshrc, nor /etc/csh.cshrc, the latter being "System-wide .cshrc file for csh(1)". Also consider /etc/csh.{login,logout} which may better suit your purposes.

Also note that /root/.cshrc and /.cshrc are hard links to the same file; changing either changes both.

objecttothis said:
running grep against umask found /.cshrc, /home/[username]/.cshrc and /etc/login.conf
umask 22 is commented out by default in the first two.
Click to expand...

Not if you're running FreeBSD 12.x or 13.x; you must have done that, but not kept originals.

objecttothis said:
Uncommenting them overrides the 027 value that I think login.conf.db is setting globally. This fixes the problem for users as long as I set these for each user and each shell.

smithi I certainly don't have your experience with this, but if an admin is wanting globally set umask for all users, it makes more sense to me than setting it in the shell config files for each user.
Click to expand...
 
objecttothis said:
OK, I think I'm closer to figuring out what is causing the problem. I ran grep -rl umask=027 and found it in /etc/login.conf.db which does not seem to be a file meant to be user edited and I never changed manually in the first place. I don't know how to regenerate this file as it seems to me that it's stale.
Click to expand...

FreeBSD has a manual page for every system file, in this case I suggest spending time with
login.conf(5).

Be aware that changes to the default: class affect root logins as well. This file is not usually used to set umask, and you'll see that 022 is the default there.

As the man says, the leading 0 is required in login.conf, but it is not on the command line, nor in .cshrc, nor /etc/csh.cshrc, the latter being "System-wide .cshrc file for csh(1)". Also consider /etc/csh.{login,logout} which may better suit your purposes.

Also note that /root/.cshrc and /.cshrc are hard links to the same file; changing either changes both.

objecttothis said:
running grep against umask found /.cshrc, /home/[username]/.cshrc and /etc/login.conf
umask 22 is commented out by default in the first two.
Click to expand...

Not if you're running FreeBSD 12.x or 13.x; you must have done that, but not kept originals.

objecttothis said:
Uncommenting them overrides the 027 value that I think login.conf.db is setting globally. This fixes the problem for users as long as I set these for each user and each shell.

smithi I certainly don't have your experience with this, but if an admin is wanting globally set umask for all users, it makes more sense to me than setting it in the shell config files for each user.
Click to expand...

Consider using /etc/csh.cshrc and /etc/csh.login instead, which are copied to user's home on account creation, and act after login.conf.db settings.
 
Sorry for extra post; it's too easy to hit the Posf button on a phone, so I was editing my reply when sonething went awry ..
 
smithi said:
Not if you're running FreeBSD 12.x or 13.x; you must have done that, but not kept originals.
Click to expand...
Nope, but this jail and associated accounts were originally setup with 11.x, so my guess is that it was using the 11.x template which is why they were commented out.
 
smithi said:
Not if you're running FreeBSD 12.x or 13.x; you must have done that, but not kept originals.
Click to expand...

objecttothis said:
Nope, but this jail and associated accounts were originally setup with 11.x, so my guess is that it was using the 11.x template which is why they were commented out.
Click to expand...

As I said above, the 'righteous' umask 22 has been in .cshrc forever, well at least since v2.0.5 c. 1996:

[base] Contents of /stable/11/etc/root/dot.cshrc

svnweb.freebsd.org svnweb.freebsd.org

To err is human, to moo bovine.
 
Perhaps, but then it was TrueNAS (then FreeNAS) doing it when the Jail was setup because I didn't even know of the existence of these files until I began learning what the default umask was doing about two weeks ago, much less go in and comment out those lines.
 
objecttothis said:
I'm using csh.
After running lynis I decided to try out an unmask of 027, but then decided that it was too much work to manage permissions of new files and folders in the webserver root, so I changed it back to 022, but new directories are still being created with 750 and files with 640 permissions.

I checked .cshrc and unmask is commented out there.
in /etc/login.conf I have

:unmask=022:\

What am I missing here? Aside from saving the file, is there anything else I need to do to successfully change the unmask?
Click to expand...

After editing /etc/login.conf you must also run /usr/bin/cap_mkdb /etc/login.conf to rebuild the database (/etc/login.conf.db)

The shell inherits these values when you login, so you should first logout and then login again to confirm that the new umask value been set.

Regardless, whenever I find myself needing to create a new file or directory, I usually execute the command(s) in a subshell with an explicit umask setting first.
( /usr/bin/umask 077; /usr/bin/touch newfile.txt )
 
You must log in or register to reply here.
Back
Top