Tag Info

Hot answers tagged

9

You can only have one group as owner. However using access control lists you can define permissions for other groups. Check if you have ACL installed issuing the command getfacl. If your system hasn't ACL installed, install the command line tools which are in the acl package with: sudo apt-get install acl With getfacl you can read the ACL information ...


9

You need write permission in the parent direct ory to delete anything from it. In your case this is /home, and as only root has write permissions here only root can delete items from it.


6

This is not an answer, rather a collection of links and thoughts in case someone else would like to study as well. Because this is quite an interesting thing. Related answer on Unix&Linux mentioning it is (or was, can't test with vanilla kernel right now) possible to dump read only binaries this way. Grsecurity was trying to fix this config option and ...


5

You can try to set umask before converting it umask 077; openssl rsa -in secure.key -out insecure.key Edit: To not affect other files in the current shell environment by the umask setting execute it in a subshell: ( umask 077; openssl rsa -in secure.key -out insecure.key )


4

When you make any changes to filesystem in recovery root shell , you have to remount the partition with read write permissions, mount -o remount,rw / . Then you can proceed with changing permissions of root directory


4

On a POSIX filesystem, every file has a user (the file's owner), a group, and permissions for the user, the group, and everyone else. For every user, access to a given file is determined as follows: if the user is the file's owner, the owner permissions apply; if the user is a member of the file's group, the group permissions apply; in all other cases, ...


4

It is not possible to have a file owned by multiple Linux groups with traditional Unix permissions. (However, it is possible with ACL.) But you might use the following workaround and create a new group (e.g. called devFirms) which will include all users of the groups devFirmA, devFirmB and devFirmC. You create new user groups with: sudo addgroup ...


4

Without something like SELinux, root can always write to files; since you're running as root you can always write. If you're not running as root, then the permissions apply; if file exists and is not writable, then > file or >> file will fail. If file does not exist, then it will be created if the parent directory is writable.


3

You can set the permissions as drwxrwx--- (770) or drwx------ (700) depending on your preference. The first allows the owner and users in the folder's group to access the directory and add new files to it, while the second only allows the owner to access the directory. There should be no difference between the first and second in your case, unless you ...


3

So, this is a Samba share, mounted on a Linux box (clients using Windows don't have the issue)? If I understand well, it could be only a umask issue. If you type umask on your client, you will probably get 0002 which means that when you create a new directory, its ACLs are rwxrwxr-x (rw-rw-r-- for files). So, if you want all your newly created folders and ...


3

You remove the execution permission on the files. Moreover you give read permission to the world on some files. Both in combination do not allow you to login. My best advise is to back your files with some live CD and reinstall


2

Assuming you are running Linux with Grub as bootloader: Boot into Boot Linux Grub Into Single User Mode Login with the root account Execute chmod 755 /etc Reboot the system I'm not sure if you can go beyond point 2. If it's not possible to login as root (which in fact should be, since the process which asks you for your password should have access to the ...


2

Think about your requirement for a moment.  Do you (might you possibly) have any executable files (scripts or binaries) in your directory tree?  If so, do you want to remove execute permission (even from yourself), or do you want to leave execute permission untouched?  If you want to leave execute permission untouched, you should use chmod o-w to remove ...


2

You should be able to restore permissions from a root shell, if you manage to start one. You should be able to get a root shell by logging in as root on the console. At this point, depending on your configuration, you may or may not be able to gain root access from an ordinary account with su or sudo, and you probably won't be able to log in under any ...


2

It's not a great solution, but: make the directory writable only by you, or some designated user or pseudo-user, or, perhaps better yet, a group (that your users are not members of), carefully write a wrapper for mkdir, and install it setuid or setgid. If you choose the group / setgid option, it could be as simple as mkdir("root_scripts/<user's ...


2

I don't think there is any way to answer how you could know what changed the permissions in the past, but you can use the lsof command to see what user or process is using a file at any given time. You could try putting that on a cron and possibly catch it. If something is randomly changing your file permissions and you don't know what it is, it may be very ...


2

A trivial but simpler solution is to chmod 700 a directory and operate inside it.


2

One way to do this is to make a blank insecure.key file first and chmod it. touch insecure.key chmod 600 insecure.key Which makes the directory look like total 28 drwxr-xr-x 2 flyte flyte 4096 Apr 17 11:44 . drwxr-xr-x 12 flyte flyte 4096 Apr 17 11:44 .. -rw------- 1 flyte flyte 0 Apr 17 11:44 insecure.key -rw------- 1 flyte flyte 1746 Apr 17 11:42 ...


2

hidepid is a mount option for procfs that hides processes from other users. There are three settings: hidepid=0: Anyone can read the world-readable files in /proc/PID hidepid=1: Users can only access the /proc/PID directories and files that belong to their user. hidepid=2: The same as hidepid=1, but the processes of other users will not even be visible in ...


2

When sticky bit is set, only the file's owner, the directory's owner, or root can rename or delete the file. The sudo command is there to enable a user to impersonate another user, including root. When user2 issues a command through sudo to become root, he's getting root's permissions, and root always has all permissions on the system.


2

As the error message states, your filesystem is mounted read-only. If you are using kernel NTFS driver, it does not mount filesystem read/write, as that is considered unsafe. Your best bet is to use ntfs-3g, which IIRC, does read/write mount by default and is considered safe for writing.


2

Starting a graphical session requires the creation of files in the /tmp directory. If your user no longer has write permission to that directory, graphical logins will fail. To see that this is the issue, switch to a virtual terminal (press Ctrl+Alt+F2) and log in normally. If the changed permissions on /tmp are the reason, your log in should succeed. To ...


2

You said you wanted to grant read and write permissions to all subdirectories and files under: /home/user/workspace/MinimalDbaseExample ... right? Octal 0777 permissions grant rwxrwxrwx symbolically. Octal 0755 permissions grant rwxr-xr-x symbolically. Octal 0666 permissions grant rw-rw-rw- symbolically. To set read/write/execute permissions to the ...


1

I found the problem. The kernel was compiled with grsecurity, which hides processes from other users. With default kernel everything works fine.


1

I don't believe it is possible to make the behavior you desire the default / general behavior. Look here for details regarding "base permissions". For files the base permission is 666 or rw-rw-rw while for directories it is 777 or rwxrwxrwx. umask may further restrict base permissions, but cannot grant additional access. In other words, umask cannot be used ...


1

Talked to the infrastructure people, and the answer is that there are extended ACLs in place that act differently based on location, and that they were erroneously set.


1

After hours searching, there seems to be different causes for this issue and different solutions for each one. I'm not an expert to provide a comprehensive answer so I hint to some frequent situations on the topic: Ownership/permission issues for mounted devices on mount points: File permissions won't change USB drive auto-mounted by user but gets write ...


1

This is an extremely common problem, if I understand it accurately, and I encounter it constantly. If I used ACLs for every trivial grouping problem, I would have tons of unmanageable systems. They are only best practice when you cannot do it any other way, not for this situation. This is the method I very strongly recommend. First you need to set your ...


1

No, this is not possible. Each file (and so also directories) can only have one user and one group.


1

find /dir/stuct/path -perm -0002 -type f -exec chmod 664 {} \; The "{}" represents the file found by find. The "\;" ends the command that needs to be executed.



Only top voted, non community-wiki answers of a minimum length are eligible