# Question about /home permissions

## bheinze

Hi all,

I created a new user by the command

```
useradd -m -G users -s /bin/bash testu
```

Now the home directory looks as follows:

```
nb ~ # ls -la /home/

total 16

drwxr-xr-x  4 root     root     4096 Dec  8 21:33 .

drwxr-xr-x 21 root     root     4096 Oct 23 17:55 ..

-rw-r--r--  1 root     root        0 May 22  2018 .keep

drwxr-xr-x 21 bheinze  bheinze  4096 Dec  8 21:48 bheinze

drwxr-xr-x  3 testu    testu    4096 Dec  8 21:36 testu
```

Why are the user directories world-readable? Shouldn't they be drwx------? I just checked and user bheinze can look into testu's files?

What did I do wrong, or what is wrong on my system?

BR

Bernd

----------

## cboldt

That's the default.

`man useradd` and see the UMASK, which is 022.

----------

## mike155

bheinze, nothing is wrong on your system. 

Read the man page of 'useradd' (as suggested by cboldt) and change the value of UMASK in /etc/login.defs.

----------

## bheinze

Understood, so this is the default setting. But why would anyone want to have the user-dirs world readable?

----------

## Jaglover

This is probably from times when UNIX environment was mostly used to share work. Unless you run a web server on your home directory the "world" is just other users who have login rights to given computer.

----------

## Anon-E-moose

If you can't trust your users, why are they allowed on the system?

The users can always make whatever they have in their own directories r/w/x only by them if they so desire.

And if you really want it locked down, then simply chmod 700 on /home/<directory> after you create a user directory. 

Or change the default UMASK (though I wouldn't recommend it as it'll probably bite you unexpectedly)

----------

## bheinze

 *Anon-E-moose wrote:*   

> If you can't trust your users, why are they allowed on the system?

 

Actually I intended to use the users as some kind of sandbox. While they might not have permission to write in my home, I don't want them to snoop in my files either.

 *Anon-E-moose wrote:*   

> Or change the default UMASK (though I wouldn't recommend it as it'll probably bite you unexpectedly)

 

Any idea why? Of course exchanging files between users is harder this way, but I don't see any reason anyway why I would want to have any user read-access to my personal files.

Thanks for your quick help & responses!

----------

## Jaglover

Look, it was like this. Users didn't have their own groups, permissions of home directory were <username>:users, however, not everything inside was shared. For instance, Mail had drwx------ by default. Nothing forbids you to restrict access to your personal files at your will.

----------

## jonathan183

I think minimum permissions required to get the task done is a good approach to take, and think this includes user home areas.

I think the following is correct and provides a functioning system - ymmv :-

The owner of the home folder (user) should have read and write access to everything in the home tree.

The owner of the home folder (user) should have execute access to directories.

For ssh to function correctly $home/.ssh/authorized_keys2 should be readable by group and other.

The parent directory of a users home directory must be executable by the user e.g. /home.

For convenience the parent directory of users home directories can be group and other executable.

If you have done a reasonable job of setting permissions then you can remove group and other permissions if necessary.

I think the below will set things back to minimum required permissions (for my systems), which then leaves increasing permissions on individual folders and files as issues are encountered. /home and /home/Gentoo have root:root owner.

Caution - the following script will nuke existing permissions on files and folders in all home areas. Consider use of selective removal of group and other permissions instead.

```
echo "This script $0 will set what the author considers to be the correct home tree permissions, and must be run as root"

echo

echo "Run in a root shell in a vt e.g. tty4 and test login and sudo -s in another vt before closing the root shell ;-)"

echo

echo "Check that /home/Gentoo contains only folders you want to chmod using the below list"

ls -l /home/Gentoo/

echo "Press Enter to continue or Ctrl-c to abort"

read

# owner read/write only for home tree (rw-)(---)(---)

chmod 600 -R /home/Gentoo

# user (owner) execute directories (  x)

chmod u+X /home/Gentoo

# could chmod 711 (rwx)(--x)(--x) for a functioning system but chmod 755 (rwx)(r-x)(r-x) for convenience

# not essential but allow cd /home/Gentoo to users home area

chmod 755 /home

chmod 755 /home/Gentoo
```

Ed: add caution note before script and update script, using chmod u+X and remove unnecessary requirement for group and other read settings for ~/.ssh/authorized_keysLast edited by jonathan183 on Tue Dec 11, 2018 1:16 am; edited 1 time in total

----------

## krinn

It's a "strange" script.

It set user /home/Gentoo to 600, then promote it to 700 (with a useless directory check), then set it again but to 755

I'm not getting why you do that

----------

## jonathan183

 *krinn wrote:*   

> It's a "strange" script.
> 
> It set user /home/Gentoo to 600, then promote it to 700 (with a useless directory check), then set it again but to 755
> 
> I'm not getting why you do that

 

Probably my lack of ability to script ...

first set permissions for files and directories in the home tree to read & write only

```
chmod 600 -R /home/Gentoo

ls / -l | grep home

drwxr-xr-x  16 root root     4096 Aug 12 22:18 home

ls -l /home | grep Gentoo

drw------- 47 root           root         4096 Dec  4 00:28 Gentoo

ls -l /home/Gentoo/jonathan-websurfer/.moc

total 140

drw------- 2 jonathan-websurfer jonathan-websurfer   4096 Jan  7  2017 cache

-rw------- 1 jonathan-websurfer jonathan-websurfer     26 Dec  9 14:07 equalizer

-rw------- 1 jonathan-websurfer jonathan-websurfer      1 Dec  9 14:49 last_directory

-rw------- 1 jonathan-websurfer jonathan-websurfer      5 Dec  9 14:40 pid

-rw------- 1 jonathan-websurfer my_net_group       119129 Dec  9 14:49 playlist.m3u

srw------- 1 jonathan-websurfer jonathan-websurfer      0 Dec  9 14:40 socket2

-rw------- 1 jonathan-websurfer jonathan-websurfer     48 Dec  9 14:07 softmixer
```

As can be seen this means directories are read/write so next fix that

```
find /home/Gentoo -type d -print0 | xargs -0 chmod u+x

ls -l /home/Gentoo/jonathan-websurfer/.moc

total 140

drwx------ 2 jonathan-websurfer jonathan-websurfer   4096 Jan  7  2017 cache

-rw------- 1 jonathan-websurfer jonathan-websurfer     26 Dec  9 14:07 equalizer

-rw------- 1 jonathan-websurfer jonathan-websurfer      1 Dec  9 14:49 last_directory

-rw------- 1 jonathan-websurfer jonathan-websurfer      5 Dec  9 14:40 pid

-rw------- 1 jonathan-websurfer my_net_group       119129 Dec  9 14:49 playlist.m3u

srw------- 1 jonathan-websurfer jonathan-websurfer      0 Dec  9 14:40 socket2

-rw------- 1 jonathan-websurfer jonathan-websurfer     48 Dec  9 14:07 softmixer
```

now set permissions on home parent folder to allow execute and read for all so users can cd to home folder from / etc

```
chmod 755 /home/Gentoo

ls -l /home | grep Gentoo

drwxr-xr-x 47 root           root         4096 Dec  4 00:28 Gentoo
```

----------

## dmpogo

Independently to the main question,    did not you want to have

```

useradd -g users

```

rather than   -G (capital) users ?

In my experience I have not encountered use case to have group 'users' as a supplimentary group.  If it is not used as a primary group - where else is it used ?

----------

## dmpogo

 *Jaglover wrote:*   

> This is probably from times when UNIX environment was mostly used to share work. Unless you run a web server on your home directory the "world" is just other users who have login rights to given computer.

 

+1.    Still often used like that.  My collaborators will often say - "pick up that data file from my directory such and such"  on the server (to which I do have login rights)

----------

## Hu

 *jonathan183 wrote:*   

> For ssh to function correctly $home/.ssh/authorized_keys2 should be readable by group and other.

 This is sometimes wrong in at least two ways.  First, some people do not use that filename.  The name authorized_keys without a trailing 2 is accepted by the default configuration, and some people will use that.  (To be pedantic, this name is not even required.  An administrator can change it in the server configuration, in which case your script will work on completely the wrong file.)  Second, sshd usually runs as root and possesses CAP_DAC_READ_SEARCH, so it can ignore restrictive permissions and read the file anyway.  In such configurations, you do not need to allow ordinary users read access to the authorized_keys file. *jonathan183 wrote:*   

> The parent directory of a users home directory must be executable by the user e.g. /home.
> 
> For convenience the parent directory of users home directories can be group and other executable.

 I agree that a user who lacks CAP_DAC_READ_SEARCH will need search permission on every ancestor directory.  However, your second statement is a bit odd.  How is it a "convenience" that the user has the permissions he needs?  Since the parent directory will not be owned by the user, it will most likely be root:group.  If user is not in group, then the directory must allow world-search to enable the user to pass the check.  If user is in group, then the directory must allow group-search to enable the user to pass the check.  Either way, it is not a convenience to grant a wide search permission. *jonathan183 wrote:*   

> 
> 
> ```
> echo "This script $0 will set the correct home tree permissions, and must be run as root"
> ```
> ...

 Why not actually test for root capability, instead of merely telling the user that root is required? *jonathan183 wrote:*   

> 
> 
> ```
> echo "Run in a root shell in a vt e.g. tty4 and test login and sudo -s in another vt before closing the root shell ;-)"
> ```
> ...

 This is good advice, but if the user permits root login on console via password, then these tests are not strictly required. *jonathan183 wrote:*   

> 
> 
> ```
> # owner read/write only for home tree (rw-)(---)(---)
> 
> ...

  *krinn wrote:*   

> It's a "strange" script.
> 
> It set user /home/Gentoo to 600, then promote it to 700 (with a useless directory check), then set it again but to 755
> 
> I'm not getting why you do that

 It is so much worse than you realize.  :Smile:   He recursively sets mode 600, starting there and working his way down clobbering every user-assigned permission everywhere below that point.  This makes every user-owned file non-executable, and all directories unsearchable.  The directory check is necessary because he wants to add search permissions to every directory below that point, but not make every user-owned file executable.  The process could have been done more simply by using chmod's relative operators.  For example, chmod u=rwX,go=.  Yes, that X is supposed to be capitalized.  Per man chmod, that means execute/search only  if  the file is a directory or already has execute permission for some user.  This is still wrong (it makes user files readable when they were not, writable when they were not, and strips suid), but it is less bad than was posted above.  I leave it as an exercise to the reader to find a way to invoke chmod that will not make a complete mess of the user's intended permissions. *jonathan183 wrote:*   

> 
> 
> ```
> # for ssh (rw-)(r--)(r--)
> 
> ...

 Clever use of shell glob rules could let you do both of these in one step, without error.  However, as above, you don't need it at all.

Why do you have your user home directories in /home/Gentoo instead of /home, as is more traditional?

----------

## dmpogo

 *jonathan183 wrote:*   

> I think minimum permissions required to get the task done is a good approach to take, and think this includes user home areas.
> 
> 

 

Well, as long as you can define well what is the task to be done   :Very Happy: 

----------

## jonathan183

Hu - /home and /home/Gentoo with chmod 711 instead of 755 I get

```
ls /home/

ls: cannot open directory '/home/': Permission denied

ls /home/Gentoo

ls: cannot open directory '/home/Gentoo': Permission denied

ls /home/Gentoo/jonathan-websurfer/.moc

cache  equalizer  last_directory  pid  playlist.m3u  socket2  softmixer
```

So I think chmod 755 is convenience rather than essential on those folders.

From my original post  *Quote:*   

> If you have done a reasonable job of setting permissions then you can remove group and other permissions if necessary.
> 
> I think the below will set things back to minimum required permissions (for my systems), which then leaves increasing permissions on individual folders and files as issues are encountered

 

I intended removing execute permissions on everything in home, I prefer to add permissions back when needed rather than leave them as they were.

I have changed the find line with 

```
chmod u+X -R /home/Gentoo
```

 and removed the modification of authorized_keys2 permissions thanks  :Cool: 

A few years ago I was running a number of distros with a common home partition so I had /home/Gentoo /home/Mint /Home/Arch - I still run Gentoo and Mint at the moment

I have user data on a separate partition I mount at /home/User-data so things which are shared between users is stored on that partition, and use a separate folder for sharing between users within the same group.

----------

## Hu

 *jonathan183 wrote:*   

> Hu - /home and /home/Gentoo with chmod 711 instead of 755 I get
> 
> ```
> ...
> ```
> ...

 Yes, but both those modes permit search (execute).  To get the convenience you show here, you need read permission on the directory, not search permission.  Your prior post said search was a convenience.  Search is a requirement.  Read is a convenience.

 *jonathan183 wrote:*   

> I intended removing execute permissions on everything in home, I prefer to add permissions back when needed rather than leave them as they were.

 That is fine if that is how you want to run the system, but that is not something that should be done on a routine basis or done lightly.  Your posts read to me like this was something that could be done without much consideration and with minimal negative side effect.  It did not draw attention to out how drastically permissions could be altered.

Also, although this is now changed, your initial script would in fact add permissions to files which the user had intentionally locked down.

----------

## NeddySeagoon

jonathan183,

 *Quote:*   

> I intended removing execute permissions on everything in home, I prefer to add permissions back when needed rather than leave them as they were. 

 

Is mounting /home -o noexec a bit excessive for your use case?

----------

## jonathan183

 *Hu wrote:*   

> Yes, but both those modes permit search (execute).

  sorry ... I meant read (711 vs 755) but typed execute   :Embarassed: 

 *Hu wrote:*   

> Also, although this is now changed, your initial script would in fact add permissions to files which the user had intentionally locked down.

  OK I guess it would force the owner to go through the same process again before sharing ... making revoking group and other access rather than nuke permissions a better approach ...

 *NeddySeagoon wrote:*   

> Is mounting /home -o noexec a bit excessive for your use case?

  I used to have home mounted noexec but can't recall why I switch it back ... maybe time to try again - especially since I tend to use /opt/user-scripts  :Smile: 

----------

## 1clue

Back in the 80s when I was introduced to UNIX and subsequently Linux, there were a couple of pretty hard traditions:

A user had access to their personal directory, that's it. Nobody had access to /var or /usr/src or any of that.

If a user wanted to share work, they set up folders within their home directory.

They could have a shared directory (usually called ~/shared) so people who were in the share group could get and possibly put files there.

They could have a dropbox folder (only user readable, but group writable) where people could put files for your eyes only

They could have ~/public_html where they could put their own web page.

There were more possibilities, but this is the standard stuff.

In order to get to those, you need to at least have rwxr-w--x on $HOME, so the users could get to the necessary folders.

I wouldn't change your UMASK, but you can change your $HOME so it's not accessible by world. Most of that stuff tends not to be used anymore.

----------

