New answers tagged

0

The risk from "inadvertently add[ing] an extraneous user to the group" is minimal. And fACLs are not obsolete. Used properly fACLs supplement the the things which are difficult to do with the base permissions system, but they do open the possibility of creating a labrynthine mess the likes of which are only normally seen on badly managed MSWindows shares. ...


1

The principle at play here is the least privilege. A chmod permission of 600 or 700 gives only the owner rights to the file, while 660 or 770 gives the same rights to the group too. Whether this is intended or not depends on the use case. Either might be appropriate. A server might - and will probably - have different categories of users (students, ...


2

Yes, you can do this, but it may not be the best design since, on some systems, such as HP-UX, the permissions of the socket file are ignored. While the permissions of the parent directory will still be applied, these may be harder to administer than the permissions on the socket file itself. Unix domain sockets provide another means for verifying the ...


3

Linux honors file permission on domain sockets, but there are Unix implementations that ignore permissions on the socket file (e.g. BSD, HP-UX). A portable program that depends on filesystem permission for security should create the socket in a directory with the desired permission rather than setting the permission on the socket file. There is also a ...


5

This is not directly insecure, as long as these files and directories have the same owner than the parent directory, that there is no hard-link allowing to bypass the parent directory permissions and that there is no exception put on the parent directory permissions (like some ACL for instance). However, I would still classify this as not prudent and not ...


0

Eliminate the shared user accounts ASAP. The only time a shared user account is necessary, is when multiple people need to access an archaic system that only supports one (or maybe only a few) user(s). The only roles worth developing are likely going to be the user and administration roles (and maybe several administration roles.) The user role is likely ...


0

I think there are multiple options for different purposes: Do you want to avoid your users use the same password for daily work and for administrative tasks (in order to limit the security threats if the commonly used password is stolen)? Do you want to limit the "power users" on some system while enabling them on others? Do you want to track (audit) you ...


0

In this case, it depends on what you want to achieve. The idea behind segreation, for example not running as root, but as a limited user for everyday activites, is that if the account is compromised for some reason, the damage is contained to the rights that the limited user account has. Segreation does NOT protect against malicious users, in the same way ...


7

You are right, just giving permissions to each user that needs them only ocasionally is not a good option. Sharing privileged accounts isnĀ“t an option too. Since you did not specified your environment, I will provide two answers: Linux/*nix You could give each administrator the option to escalate to a higher privilege level on his operational account. ...


1

You could build a login that creates a session with a certain user, who then get's some sort of tracking cookie or thing-ie. With this, you still could trace the user and his actions. Usually you do this by using a framework like Play! or Spring. Examples for Play! can be found here and here. The process is similar on different frameworks: User logs in - ...


5

If your server has been compromised, then assume they have root access. Even if it appears that you removed offending shell scripts (which a lot of times is all the "clean up" entails), it's entirely possible for them to dig deeper into the system. You have no idea what exploits exist for the server software, so it's entirely possible that uploading a simple ...



Top 50 recent answers are included