/home/user Permissions?

English Install/Boot/Login
1

Hi

Whilst looking for something else today i came across this info, at Understanding Linux file permissions - Linux.com

  • home directories
  • The users' home directories are important because you do not want other users to be able to view and modify the files in another user's documents of desktop. To remedy this you will want the directory to have the drwx______ (700) permissions, so lets say we want to enforce the correct permissions on the user user1's home directory that can be done by issuing the command chmod 700 /home/user1.>

Curious, i checked mine, & am a bit surprised / puzzled to discover:

gooeygirl@linux-Tower:/home> **ls -la**
total 12
drwxr-xr-x  4 root    root    35 Nov 12 00:34 .
drwxr-xr-x  1 root    root   214 Oct 25 14:14 ..
drwx**r-xr-x** 26 rachel  users 4096 Oct 29 18:25 rachel
drwx**r-xr-x** 78 gooeygirl users 4096 Nov 29 16:46 gooeygirl
gooeygirl@linux-Tower:/home>

Should i change both these to the more restrictive Permissions per the article pls? If yes, am i right to suspect that i should not include the recursive option [as i assume that certain files / directories within, might need their own special Permissions]?

2

The permissions as you show them allow users in the group users and all other users (thus in fact all users) to see what files/directories are in the other ones home directory (because of the r permission) and also what their permissions, size, owner, group, timestamps are (because of the x permission). They can not change anything of this (including adding/removing files/directories) in the other ones home directory (because of the lack of w permission).

When a user does not want this for other users then those in his own group, (s)he can change this by removing the r and x permissions for e.g. others(the world:

chmod o-rx $HOME

Similar for group.

Not that in your case there is no practical difference between group and others because you have only two users both in the same group.

This is a responsibility of the users themselves. root can only set those permissions as a suggestion (e.g. at the creation of a home directory), but after that the user can change that any moment to what (s)he thinks (s)he needs.

Talking about what is “correct” is sheer nonsense in my opinion. The “user/group/others partition and their permissions” mechanism is there to be used to need.

Using the -R option on chmod is again something you may need or not. When you want to remove all r, x (and logicaly then also all w) options from all files starting from a directory (in this particular case your home directory) up to the last file in that part of the directory tree, then yes. But the question is: do you want this.

When a directory has permissions rwx------, only the owner can look/do anything in that directory (and further up), thus granting group/others permissions in files there is useless, thus removing group and others permissions from those files will not hurt anybody. OTOH having them on does not hurt either.

In those times when I was using Unix as a professional, I always removed the permissions from at least others (and often also for group) from my home directory. As an extra I did so for all files that belonged to me (mostly in my home directory tree of course). And I added

umask 027

or more resrtictive

umask 077

in my ~.profile to avoid new files to be created with those permission on where I wanted to have them off.

Nowadays only my wife and I have users on our systems (not in the group users btw) and I am less restrictive.

In short: every Unix/Linux user should have a good understanding about the user/group/other and permissions concept. The user should then design a policy on how to use them in a particular case (may be different for every system (or group of systems) where the user has a userid). And then implement that policy and keep to it.

3

That’s really wonderful info, thank you Henk. It seems therefore my own comprehension of this matter before posting was ok, but your explanation was substantially more useful than my own attempts to myself here. You might [or might not] be interested in the distro permissions comparison post i’m about to create, below…

4

A comparison that possibly interests nobody but myself, but anyway, fwiw:

All these do drwxr-xr-x for their /home/genericusername

# Clean install of **oS** **TW** in VM, back on 17/5/17, dup'd to TW 20171102 [Plasma 5.11.2] on 4/11/17. 
gooeygirl@linux-sr0s:/home> ls -la
total 28
drwxr-xr-x  4 root    root   4096 Oct 12 11:33 .
drwxr-xr-x 23 root    root   4096 May 17  2017 ..
drwx------  2 root    root  16384 May 17  2017 lost+found
drwxr-xr-x 20 gooeygirl users  4096 Nov  4 19:28 gooeygirl
gooeygirl@linux-sr0s:/home> 




gooeygirl@linux-i4ba **oS Leap** 42.3 VM]:/home> ls -la
total 28
drwxr-xr-x  5 root    root   4096 Oct  3 00:03 .
drwxr-xr-x  1 root    root    166 Oct  2 23:25 ..
drwx------  2 root    root  16384 Jun 17 00:26 lost+found
drwxr-xr-x 18 rachel  users  4096 Jun 17 12:45 rachel
drwxr-xr-x 22 gooeygirl users  4096 Nov  4 14:56 gooeygirl
gooeygirl@linux-i4ba:/home> 




gooeygirl@gooeygirl-VirtualBox-**Mint17.3** KDE4 -VM:/home > ls -la
total 12
drwxr-xr-x  3 root    root    4096 Feb 10  2016 .
drwxr-xr-x 23 root    root    4096 Jun 28  2016 ..
drwxr-xr-x 74 gooeygirl gooeygirl 4096 Oct 20 09:14 gooeygirl
gooeygirl@gooeygirl-VirtualBox-MintKDE-VM:/home > 




gooeygirl@gooeygirl-VirtualBox-**Mint18.2** Plasma5.8.7 /home $ ls -la
total 28
drwxr-xr-x  4 root    root     4096 Sep 10  2016 .
drwxr-xr-x 23 root    root     4096 Oct 14 13:27 ..
drwx------  2 root    root    16384 Sep 10  2016 lost+found
drwxr-xr-x 28 gooeygirl gooeygirl  4096 Oct 14 13:57 gooeygirl
gooeygirl@gooeygirl-VirtualBox /home $ 




gooeygirl@Maui-VM **Maui17.03** Plasma 5.10.2]:/home$ ls -la
total 28
drwxr-xr-x  4 root    root     4096 Mar 26  2017 .
drwxrwxr-x 25 gooeygirl network  4096 Oct 31 13:51 ..
drwx------  2 root    root    16384 Mar 26  2017 lost+found
drwxr-xr-x 46 gooeygirl gooeygirl  4096 Oct 31 14:08 gooeygirl
gooeygirl@Maui-VM:/home$

All these do drwx------ for their /home/genericusername

[gooeygirl@gooeygirl-pc ([b]Manjaro Plasma5.11.3) home]$ ls -la
total 32
drwxr-xr-x  5 root    root     4096 Nov 25 13:51 .
drwxr-xr-x 18 root    root     4096 Nov 26 13:27 ..
drwx------  2 root    root    16384 Nov 25 13:20 lost+found
drwx------  4 rachel  rachel   4096 Nov 25 13:51 rachel
drwx------ 36 gooeygirl gooeygirl  4096 Nov 29 20:57 gooeygirl
[gooeygirl@gooeygirl-pc home]$ 




[gooeygirl@gooeygirl-pc ([b]KaOS Plasma5.11.3 VM) home]$ ls -la
total 4
drwxr-xr-x  3 root    root    21 15.01.2017 17:47 ./
drwxr-xr-x 21 root    root   272 04.01.2017 05:27 ../
drwx------ 20 gooeygirl users 4096 21.11.2017 19:31 gooeygirl/
[gooeygirl@gooeygirl-pc home]$ 




[gooeygirl@localhost ([b]Fedora26 Plasma5.10.5 VM) home]$ ls -la
total 28
drwxr-xr-x.  4 root    root     4096 Feb 11  2017 .
dr-xr-xr-x. 21 root    root     4096 Oct 19 18:08 ..
drwx------.  2 root    root    16384 Jul  8  2016 lost+found
drwx------. 18 gooeygirl gooeygirl  4096 Oct 19 20:30 gooeygirl
[gooeygirl@localhost home]$ 




gooeygirl@gooeygirl-VirtualBox (**KDE Neon** Plasma 5.11.3):/home$ ls -la
total 40
drwxr-xr-x  5 root    root     4096 Sep 21  2016 .
drwxr-xr-x 24 root    root     4096 Nov 22 19:03 ..
drwxr-xr-x  3 root    root     4096 Sep 21  2016 .ecryptfs
drwx------  2 root    root    16384 Sep 21  2016 lost+found
drwx------ 24 gooeygirl gooeygirl 12288 Nov 22 20:19 gooeygirl
gooeygirl@gooeygirl-VirtualBox:/home$

In each of those VMs i have definitely NOT altered those permissions; the status above is each distro “out of the box”.

5

As I tried to express above, it is not so important what the defaults in user installation (and thus creation of home directories) are on system installation because:

  • the system manager/administrator can change those defaults, and/or deviate from the defaults on user creation;
  • the user can adapt to his own needs.

The important thing is knowledge. And the owner/group/others vs. read/write/execute is one of the most important things every Unix/Linux user (except those locked in in a prepared environment) should learn first.

I guess there is no problem to find documentation on the internet. At least for Dutch speaking users there is: https://forums.opensuse.org/showthread.php/488565-korte-uitleg-wie-mag-wat-met-elk-bestand#post2570547

6

Let me provide an example from a desktop system with 2 “home” partitions (for “human” users):


 > l home*/
home/:
total 4
drwxr-xr-x  6 root      root        68 May 10  2017 ./
drwxr-xr-x 24 root      root      4096 Nov 22 16:41 ../
drwxr-x--T  3 fints     fints       20 Aug 20  2015 FinTS/
drwxr-xr-t  4 test-user test-users   36 Jul  6 09:00 Test-Users/
drwxr-xr-t  4 users     users       28 Jul  6 08:37 Users/
drwxr-x--T  3 clubs   clubs     20 Aug 20  2015 Clubs/

home01/:
total 8
drwxr-xr-x 12 root    root     152 Jul  6 09:20 ./
drwxr-xr-x 24 root    root    4096 Nov 22 16:41 ../
drwxr-xr-t  3 pictures  pictures    21 Aug 20  2015 Pictures/
drwxr-xr-x  3 root    root      52 Mar  5  2012 BackupCopies/
drwxr-xr-t  6 root    root     131 Aug 30  2014 Software/
drwxr-xr-t  3 test-vm test-vm   24 Sep 23  2016 Test-VM/
drwxr-xr-t  3 user-vm user-vm   21 Jul  6 09:22 User-VMs/
drwxr-xr-t  5 users   users     41 Aug 20  2015 Users/
drwxrwx--T  2 tmpxfer tmpxfer 4096 Oct 25 15:58 tmpXfer/
 >

What’s going on here?

  1. There are more than a few (human) user groups: ‘users’; ‘pictures’; ‘clubs’; ‘fints’; ‘test-users’; ‘test-vm’; ‘user-vm’; ‘tmpxfer’.
  2. Each user group directory within the “home” directories, is owned by a pseudo (non-human – locked – no login) user within the concerned user group.
  3. Not all user group directories can be accessed by “other” users (those who are not group members) or “all” users.
  4. The use of the “T” bit (the “restricted deletion flag” or “sticky” bit) on the user group directories ensures that, the files within the directory can only be deleted by the file’s owner – the “sticky” behaviour is historical and only has a meaning for regular files (not directories).
  5. The “tmpXfer” directory is a place where users who are members of the “tmpxfer” group can transfer files to users who do not have read access to the other user’s directories – not all users have e-Mail accounts and, network drives also need to respect any security policies . . .

A deeper understanding of the permission bits associated with each file – a directory is also a file, as is a socket and, a few other things as well . . . – can be gained from the man pages of the “Linux Programmer’s Manual” and the “POSIX Programmer’s Manual” and, the pages referenced:

  • “man 2 chmod”
  • “man 3p chmod”
  • “man 2 unlink”
  • “man 2 execve”

My personal preferance is for the “Linux” explanation.

7

Be aware that at the moment Dolphin and Konqueror Cannot Set Extended Permission Bits… Note particularly (my) bold…

This from the 42.3 release notes, currently also applies to the TW version.

3.3 Dolphin and Konqueror Cannot Set Extended Permission Bits

The versions of the KDE file managers Dolphin and Konqueror that are shipped with openSUSE Leap 42.3 cannot set “Extended Permission” bits (GID, “Sticky”). Additionally, closing the Dolphin permissions dialog by clicking OK clears existing extended permissions bits.

To avoid such issues, edit permissions with chmod (command line) only.

8

Whoops… :embarrassed: Was broken, my apologies…

Found whilst looking for the original bug report:

https://cgit.kde.org/kio.git/commit/?id=9ac7832b859bfcbc88448c4ae0f6dc14b2d54a06

9

IMHO there is hardly a use case for normal users to set these bits. Thus only root may want to manipulate them. I never use any GUI tool for doing these things.

The above example is contrary to what I say, but I see this as a very special case that will not be repeated by many. And I have also the idea that only the system manager is using those “group users” (their passwords being unknown to the real end-users) and thus will do so from the CLI.

10

Just a personal opinion.

I always leave home directory permissions at 755 (or “drwxr-xr-x”). It doesn’t bother me that other users can see what is in my home directory.

As an educator, I used to tell my students that they were welcome to look around in my home directory and by “bin” directory (mostly shell scripts) to see how I do stuff.

However, I do have a subdirectory named “PRIVATE” with very restrictive permissions. And my “Mail” subdirectory has restrictive permissions. And I also have a restrictive subdirectory “Private” (due to used “ecryptfs” and its private directory setup).

At present, now that I’m retired and at home, the only other users who can see my files are also me (test account, for example).

11

Are you even on a multi-user machine … or is this your home desktop …

12

A Linux system is always a multi user system.
When you forget that (or do not understand that) you will from time to time have difficulties to understand your system.

13

It is, as you say an example; but, UNIX®, and Linux, and anything else that looks or smells like UNIX®, has all these permissions on files;Regardless of the type of file – a “regular” file or, a directory (file) or, a socket (file) or, whatever else.
It is, IMHO, important that, anyone learning UNIX® file permissions needs to be aware of all the permission mechanisms which UNIX® provides for files.

One of the beauties of UNIX® user definitions is that, pseudo-users can be defined which defeat an attempts to login as that user – the shell is either ‘/usr/sbin/nologin’ or ‘/bin/false’ – the user’s entry in ‘/etc/shadow’ is empty, except for the ‘login name’ and ‘encrypted password’ fields – the password field is either set to the value “!” or “*” – an invalid result of ‘crypt’.

Take a look at a typical ‘passwd’ file – there’s a sack full of password-less, impossible to login to, pseudo-users, for example (just a few):


messagebus:x:498:496:User for D-Bus:/run/dbus:/bin/false
mysql:x:60:484:MySQL database admin:/var/lib/mysql:/bin/false
nagios:x:383:471:User for Nagios:/var/lib/nagios:/bin/false
nm-openvpn:x:382:469:NetworkManager user for OpenVPN:/var/lib/openvpn:/sbin/nologin
ntp:x:74:495:NTP daemon:/var/lib/ntp:/bin/false
polkitd:x:494:492:User for polkitd:/var/lib/polkit:/sbin/nologin
postfix:x:51:51:Postfix Daemon:/var/spool/postfix:/bin/false
pulse:x:489:488:PulseAudio daemon:/var/lib/pulseaudio:/sbin/nologin
quagga:x:485:482:Quagga routing daemon:/run/quagga:/usr/bin/false

Exactly this approach, can also be used to manage the “home” directories of groups of users which need to be isolated from one another.
[HR][/HR]Where is this approach useful on a private, non-business, machine?

  1. Users for home banking (HBCI) transactions – isolation from the “normal” login used for e-Mail and other WWW sessions.
  2. Users for the management of club members and finances – also HBCI transactions and, data privacy issues – legal, laws of the land, tax department issues – somewhat easier if a dedicated machine is used . . .
  3. Users which need to run a VM with MS Windows in it because, your camera’s manufacturer doesn’t supply a RAW file application for Linux – currently only those folks who own a SIGMA camera and, haven’t, yet, purchased a Mac Pro, are affected by this . . .

Actually, running Digikam and, maintaining the Digikam database, in a user environment isolated from the “normal” user is actually super comfortable and relaxed – no worries that a stupid mistake while messing about with the system will wipe your collection (of possibly thousands) of photos . . .

14

There’s a comment from me on the related KDE Bug Report 365795 “Setting extended permissions do not work”:The change made means that the extended permission bits are no longer clobbered but, the original issue reported, remains.
The KDE developer’s final comment is:

but in any case better than the status quo

The root cause is, the current inability of the Qt WebKit to support the UNIX® extended permission bits of UNIX® files.
There are rumours that, this will be addressed with a future release of Qt but, not yet . . .