i created 2 users: user1 and user2.
from user1 i can access and open all files of user2.
from user2 i can access and open all files of user1.
how to isolate each user from each one?
thanks
user1 should remove read/write/execute permission for the world when he does not want them to be accessed by other users outsiide his group.
He also must remove them from groupd access if he wants them not to be accesed by users in his group.
That is the standard way of permitting of r/w/x to u/g/o in Unix/Linux. Try to read some tutorial on it.
Let one of your users check the permission of one of those files with
ls -l <such-a-file>
BTW the default is that users create their files with rw-r–r–. This is that user and group and others can read the files, but only the user can write to them. Thus when you say “can access and open all files” (what is the difference between access and open?) you might be more specific in telling about read-only, or read and write.
i change access rights of home folder with dolphin.
i change for group and others right to “forbidden” .
is it sufficient?
Sure for normal users but remember that the root user has full access to all
That is something I have noted as well.
I changed it for the second user manually and then changed the default permissions with YaST User Manager, so that all future users will not have these permissions.
In addition to this, I have created an admin group for root users and left the ordinary users in their user group. Also added a group for our children, and then went to set each group permissions. For example children have no sudo permissions at all, regular users do, etc.
Could probably also use umask -S to change the defaults quickly.
However, I have to admit, that I was quite surprised, when I at first noticed the fact, that all users have access by default to all user information, even if the other user is in a different group.
I do not know about “forbidden”. hat is only the interpretation of a GUI program of he underlying permissions.
You can see who is the owner (user and group) and what are the permissions with
ls -l
of the file.
Every user is responsable for the protection he wants.
You can help him by teaching him how to set his umask in a way that permissions are more restricted on creation that the default 022. I would e.g. make it 027 to not have any permissions for the world on creation. Or even 077 to have also none for the group. The user can set that in his ~/.profile by adding e.g. the line
umask 077
As systems administrator, you can also change the default umask for new users you create ((thus not for existing user) in YaST > Security and Users > User and group management and then the Default for New Users tab.
The distribution (and I guess most distributions) has more of these. The problem is to find something between absolute security at one side and usability at the other. The fact that often people that have even no idea about multi user operating systems (and having a Microsoft Windows only background) try out Linux. When they are then confronted with policies that restrict them to much and inexplicable (from their point of view), they might stop using Linux. I think the defaults here are dictated by the fact that most people do have only one user created (thus who against to protect?) and when they occasional create a second user, it might only be for a test (being the same physical person) and then access to your “own data” being blocked might not be what you expect.
In any case, since I started using Unix (somewhere in the seventies) the first thing I did after getting an account on a system, was adding an umask to my .profile. Second may be chmod go-rwx on all files already there in my home directory.
As I said earlier, every user is must protect him/herself. And basic knowledge about ownership/permissions is a prerequisite for every Unix/Linux user. The system manager/administrator can not protect the user from the user’s stupidities or lack of knowledge. He/she can only point to good documentation and best practices.
Well looking at it this way, Henk makes a good point here.
However, maybe it would be a nice idea, to offer such an option during install or at least advice users of this fact. If - even though maybe not too common - the machine is used in a multi user environment or someone expect their data to be protected, is made aware of it. From my understanding of Windows, if you create a user account, all their files and folders (with exception of the Public one) are protected from being viewed by other users, unless you share them, or use an administrator account, with your admin password, to override protection and enter it.
openSUSE (and many other distros) create a Public Folder in the home directory by default, which I would have thought, is for the exact same purpose, being publicly open to everyone.
We already have some of those: “automatic login” and “use the same password for root as for the first created (at installation) user”.
Specially the last one is >:) to me.
But people just leave those defaults a they are, not understanding the ramifications. Your proposal would only add to those, for most not understandable, choices.
It is also completely against the way the installation process is developing. Earlier you could in the beginning of the installation uncheck a box with default Automatic installation. You could then do e.g. network configuration and more yourself. It is removed. You now have to swallow all the “automatic” configuration and then after wards have to redo those to your liking.
And when you, as system manager, want to use your system really multi user you should develop a policy on how to do that (who will belongs to which user group, what default umask do they get, who is responsible for user space backups and in what way, what user education, etc.) it is not too difficult to implement that on a fresh installed system.
Don’ forget that while the OP here complains that users can read other users files (well, he talks about “access” and “opening” without really specifying that, but I guess he means “read”), most complaints here are about users not being able to read/write files from/to other places then within their own home directory. I admit that those complaints are mostly about mounted file systems, but IMHO it illustrates that users are interested in access, not in security.
When the umask (and thus most user’s file permissions) would have been more restrictive from the installation on, I assume that complaints in the style “why can’t I see the pictures my children have in their home directory” would appear.
Well, looking at it this way, I suppose you are right 
And yes, I do agree that using the same user and root password is a bad idea, to say the least.
Well it was not much of an issue anyway. I was just surprised, but it was also easily changed afterward. After all, once install is done, the true setup and configuration begins. :=)
Exactly :shake:
Unix – emphasizing openness since the 1970s 
I like it that way. But, long ago, I did create a directory “PRIVATE” with more restrictive permissions, and I put some stuff there.
This is my view, as well. I suppose we do need some simplification in the options for newcomers, but the automatic login and same password for root defaults should not be as they are, IMHO.
The current suse policy on allowing users to see each others files is insane. Separate user should equal user isolation. Its what one would expect (principle of least surprise) and the one that should be implemented. Can you see other users emails when you log onto your email account? The rare and trivial use case of “seeing your child’s photos” pales into comparison of the child getting to read the parents documents - letters from doctors, adoption correspondences. These are things that can change peoples lives.
Checking the “/etc/skel/” skeleton directory on this KDE4 Plasma 13.2 machine revealed only a “public_html” default user directory – which is the default directory for users to publish via an Apache Web Server running on that host.
[HR][/HR]“KDE4 Plasma” and “KDE Plasma 5” both create a directory (for English language users) named “Public” (in addition to the “public_html” directory copied by “useradd” from the “/etc/skel/” directory) – for other user languages, the name is a translation suitable for that user.
And now, “KDE magic”:
- Using Dolphin, “right click” the “Public” directory.
- Choose “Properties” and then select the last tab: “Share”.
- You will notice that a “Samba” share to the MS Windows world is offered.
[HR][/HR]Bottom line:
- The user’s directory “public_html” is used by the Apache Web Server for user web sites.
- The KDE Plasma user’s directory “Public” (language specific) is meant to be used for shares to the MS Windows world via Samba.
Given the openSUSE (and most other Linux distros also and as well as) default “umask” value of “022” – meaning “u=rwx,g=rx,o=rx” – your problem description seems to be somewhat strange:
- From what you have described, by default users with the same User Group can not only read each others files, they can also write to files located in another user’s (within the same User Group) directories.
Please check the value of “UMASK” in the system file “/etc/login.defs”.
[HR][/HR]And now, a solution for the issue you have raised:
- Understand UNIX®, and therefore also Linux, User Groups and, Group privileges.
- Given that User Groups usually work together, it is reasonable that users with any given Group can read the most
of the files of other users with that Group. 1. Users who are not members of a given User Group, should not automatically be able to read files produced by the members of that
User Group.
Please be aware that, there are user directories which are private: take a look at the protections on your “.local/” “.config/” and “.kde4/” directories . . .
At a system level, check the protection and group of “/etc/shadow” – the place where the local passwords are stored.
Solution:
- Create pseudo System Users (no login, no shell) who are the owners of User Group directories below “/home”.
- Place the system’s user home directories group for group within those User Group directories.
- Change each user’s group to the User Group where their home directory is located.
- Set up the protection on the User Group directories such that world access to that User Group is not possible.
- Use the “T-bit” on directories to ensure that only the owner can change the directory’s contents.
- Consider setting up Group login scripts to ensure that each user’s login has a “umask” value which prohibits world access.
- Consider forcing via system administration that, user directories within specific User Groups do not have any files with world access – need to run regular cron jobs to ensure that the policy has been enforced.
Any further security enforcement is IMHO better served by the Security-Enhanced Linux (SELinux) kernel.
Given that, the default protection on each Linux user’s “.local” directory is “no world” and “no group” access, this is per default not an issue. Assuming of course that the user’s local mail directory is located in “~/.local/share/” ]
> l /home/Users/test01/.local/
ls: Öffnen von Verzeichnis /home/Users/test01/.local/ nicht möglich: Keine Berechtigung
>
Q.E.D. but, my apologies for have the default system language of German.
Hi Gerry.
I attempted to address this issue during the Leap 42.2 Release Candidate testing – it was discussed and, the decision was to leave things as they are – for the moment.
IMHO, the current situation is acceptable for folks moving from the Redmond world – it does however, mean that also the default (first set up during installation) user needs to type in a root password for all system related tasks – that user is, AFAIK, not per default a member of the “root” User Group . . .
Best regards
DCu
I can not really understand this. An umask does not mean that the not masked bits are to be set at file creation, it means the the masked bits are not set (even when asked for by the creating process). Thus when the creating process aks for rw-r----- and the umask is 022, the result will be rw-r-----. When the process aks for rw-rw-rw-, with the same umask the result is rw-r–r–.
When permissions of a normal file are rwxr-xr-x, only the owning user can write to it and all other users can read and execute it (the executing making only sense when it is something that can be executed like a binary program or a script).
When they are of a directory, the owning user can read and write to the directory (that means listing it and creating/removing files in that directory) and read the inodes where the directory entries point to. The other users can only read the directory and the inodes, but can not create or remove files (i get the idea that you say above that that would be possible, it is not and easy to test).