Saying that to a member who has been registered on these forums since 2012 is odd.
Saying that to a member who has been registered on these forums since 2012 is odd.
In general, that statement is not true: Even in various Linux distributions, it depends on how the user's directory permissions are set (as others have already explained). That in turn depends on the default of how the Linux distribution configures new user's directories. I agree with previous posters that Ubuntu (and Debian) seem to default to permissions being restricted today. This is an example from a Raspbian system:
ls -lF /home/
total 12
drwxr-xr-x 3 electrician electrician 4096 Jan 11 12:14 electrician/
drwxr-xr-x 3 nobody nogroup 4096 Jan 11 12:14 nobody/
drwx------ 17 plumber plumber 4096 Jun 22 10:40 plumber/All you need is a flie monitor daemon that has been configured to silently change those bits.
Well, I like the purple devil. Because doing this is devilishly difficult, and will make someone purple in the face. If the daemon runs asynchronously (for example once every minute it scans the whole file system), it is lacking ACID properties, and there will be a race condition window during which the files are not protected. By the way, scanning a large file system every minute is somewhere between insane and impossible; on my home machine (3TB home file system, about half full, with perhaps a quarter million files) it takes about 4 minutes to check the attributes (including permissions) of all files.All you need is a flie monitor daemon that has been configured to silently change those bits.
I have a bunch of misfits roaming our systems that constantly
chmod -R 777 their entire home directory 
Might as well just set their home to /tmpI have a bunch of misfits roaming our systems that constantlychmod -R 777their entire home directory
Oh, and they also litter files with usernames and passwords
yeah, that kind of stupidity is painfully common. Backup systems do sweep those up and propagate them. And then people complain about 'leaked passwords!', when they did that to themselves to begin with, and won't admit to that. Just try explaining to your boss why that is a bad idea! Bosses don't want to be taught, much less to be led to a realization that they did something moronic, esp. if their own job/promotion is on the line.
I don't know about FreeBSD, but about 5 years ago I changed the rights on CentOS 6, after which some programs stopped running because they were installed with different rights and they demanded strictly defined rights .Had to restore default rights. And in Centos, a user with his rights cannot go to another user's directory. Only with root rights. So I better move my files to /root
I don't know what you mean when you say "rights". In Unix (which includes BSD and Linux, in particular various distributions such as CentOS), there are no "rights" that a user has. Except for two: A user is either root (the technical definition of that is that they have UID zero, not whether their username is root), or they are not. And they are either a member of the wheel group (the group with GID zero, on most Linux distributions that's called the root group, but again the name doesn't matter, the numeric GID does), or they are not.
That is neither specific to CentOS, nor to the root directory. I can trivially create a directory /home/bob, the home directory of user bob, which no other users can read, and therefore they can't find files in it. All I need to do is to set the permissions of /home/bob to be 700 (a.k.a. rwx------).
All you need is a flie monitor daemon that has been configured to silently change those bits.
Something like sysutils/inotify-tools could help, but for large directory trees/lot of files multiple instances should be used.
My understanding is that what OP saying "right" is actually "priviledge", as these are confused quite often.
Yeah, OP does need to understand the permissions system on UNIX better. fmc000 was right about that.
So what's the problem? Files in a user's directory need to be safe from other users' mistakes. That is a sensible default.
I think the "problem" is that by default FreeBSD gives "o=rx" permissions on user home directory in the adduser command, which has been the default in all *nixes until recently.
Maybe this in adduser(8)?
-M mode
Create the home directory with permissions set to mode, modified
by the current umask(2).pw groupmod -n wheel -d user
pw groupmod -n operator -d userwheel and operator groups. Membership in those groups is required if a user is to be able to access admin privileges (via su(1)). Well, speaking OP's language, membership in wheel and operator groups are what it takes to have "admin rights". Gotta think about things in forward AND reverse.If only certain users should have certain user creation configurations, they require individual settings. For a non-default, custom general user creation configuration, adduser(8) gives the possibility to create a /etc/adduser.conf file.
adduser -C and answering the options settings.My assumption is, if changing the current default, it should only be done on brand-new point-zero release branch such as upcoming 15.0 to avoid POLA violations.
I completely agree. Do it on a "dot zero" and be done with it.
Understood; saying "Linux" to mean "distributions based on Linux with additions by Canonical/Ubuntu/RedHat" is like saying "Kleenex" to mean "tissues to blow your nose" or "Xerox machine" to generically mean "copy machine".
Exactly. As a former manager used to say "This is not a problem that is unique to $currentworkplace"
ls -al /home
total 32
drwxr-xr-x 5 root root 4096 14 juin 21:35 .
drwxr-xr-x 19 root root 4096 17 juin 22:34 ..
drwx------ 15 jo jo 4096 16 juin 11:54 jo
drwx------ 2 root root 16384 14 juin 20:24 lost+found
drwx------ 24 mic mic 4096 17 juin 21:21 micInteresting. Not even "group" access. Which given the trend of "every user has their own group" is also a reasonable thing. Thanks for showing.