First, there is no "standard Linux ACL". Default file permissions can vary by system and by distribution; most distributions seem to have default permissions of 644
or 664
, but that's not inherent to the Linux kernel, and the proper umask
depends on the system.
More broadly: whether files are defaulted to world-readable is a security flaw or not strongly depends on what specific threats you are concerned about. If default permissions are world-readable, that means all users on the system can read files not specifically marked private. That's not necessarily a bug -- in a multiuser environment, you could plausibly declare that users will typically be sharing files, and provide a ~/private/
directory by default for files that they don't want to be shared; people can by default read anything directly under your home directory, but on the flipside sharing is easier. There's a tradeoff, which is often worth making.
Furthermore, the default permissions on files don't change on a per-folder basis. If users want to keep some things private and share other things, and don't want to chmod
lots of things, you have to set permissive default permissions. You then make certain folders which will have private stuff have more restrictive permissions. You can't do the reverse; if you want to make it possible at all to have someone have a Public
directory without learning chmod
, you basically have to implement it this way. It's really easy to restrict access to a file beyond what's in its permissions; granting access beyond its permissions is not possible (you have to change the permissions).
That's because you're wrong when you say that a 0700
home directory doesn't secure anything. A folder's x
bit controls access within the directory. If a user has no execute permission on /example/directory/
, then they cannot access anything within /example/directory/
. Even if they know that /example/directory/a
is a file. Even if they have read permissions on that file. Even if they own that file: you can't access a file unless you not only have the permissions on that file, but also have execute permissions on all parent directories of that file. The implication is that you can secure a subdirectory much more easily than you can make an especially open one.
In your case, the Documents
directory is 700
; probably the other "user-friendly" directories (this is an awful term for it, but I mean things like Documents
, Desktop
, Downloads
, Music
, etc. -- stuff that's designed for the average user to use to hold their normal files) are as well. Provided you store your documents there and not in custom subdirectories of your home directory (or directly in your home directory), no one else has access. Your home directory is intended to contain mostly config files that are expected to be there; most personal files are meant to go in a default (secured) subdirectory. If you store things directly in a home directory, they're visible, but that's not what your OS is pushing you to do. If you create a new subdirectory of ~
and want it private, set its permissions to 700
; if you want it public, set it to 755
(if you want people to be able to access files if and only if they know the name, 711
). But the expectation is that your private stuff doesn't go straight in ~
, and that the places your documents do go is already secured.