Tag Info

New answers tagged

0

if you have a systemd service on CentOs7 you need to stop the service and enable it again to have it fixed systemctl stop httpd vi /usr/lib/systemd/system/httpd.service # add this [Service] UMask=0002 # safe the file with esc ZZ # enable and start apache again systemctl enable httpd systemctl start httpd Then the funny part is that i have chmod 774 ...


1

Example of changing all the directories to 755 (-rwxr-xr-x): find /opt/lampp/htdocs -type d -exec chmod 755 {} \ Example of changing all the files to 644 (-rw-r--r--): find /opt/lampp/htdocs -type f -exec chmod 644 {} \; This would make all the files executable, while not unnecessarily setting execute permissions on the directories themselves. Credit ...


5

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 ...


1

Lets add some Debugging Info, like so: $f = fopen('mmascript.m', 'w'); echo "fopen complete." fwrite($f, "#!/Applications/mma/Contents/MacOS/MathematicaScript -script\n"); echo "fwrite 1 complete." fwrite($f, 'Print[100]'); echo "fwrite 2 complete. fclose($f); echo "close complete." chmod('mmascript.m', 0777); echo "Permissions Successfully Changed." ...


1

The FAT formatting won't allow you to set any permissions. There is no way to change that since FAT can't store that kind of meta-data. (Well, actually, from Linux side, you can specify permissions while mounting the FAT device, but the permissions will be the same for all that device and I think you can't change the mount options of your router) NTFS ...


0

As per this thread "Re: Cannot change permission of /var/empty" @ https://www.cygwin.com/ml/cygwin/2015-02/msg00784.html you should use 'setfacl -b /var' to strip the ACL on the directory and then perform the above commands as per Miline's answer. It just worked for me on Windows (8.1). If I had 50 reputation points I would of just posted as a comment.


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 ...


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.


-1

What are sticky bits ? A sticky bit is a permission bit that is set on a directory that allows only the owner of the file within that directory or the root user to delete or rename the file. No other user has the needed privileges to delete the file created by some other user. This is a security measure to avoid deletion of critical folders and their ...


0

As I can see the ntfs partition in mounted in /run/media/dazz/943C95C53C95A332/ so it can be automounted. In the case some distribution on default mount ntfs partitions with read-only flag and most with no-exec option. You are able to remount partition manually with -o rw,exec or refer to your distro manual to set automount options.


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 ...


1

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


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 ...


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 ...


0

In fact it seems that the system was more affected that the log was saying! maybe because of the dev folder, maybe symlinks... don't know but after crawling forums etc and trying folder by folder, I finally saved the server with for package in $(rpm -qa); do rpm --setperms $package; done A special thx for @Gilles and his superb answer A special NO Thx! ...


0

You could investigate using auditing to find this. In ubuntu the package is called auditd. Use that command to start a investigation if a file or folder: auditctl -w /var/www/foo -p a -w means watch the file/folder -p a means watch for changes in file attributes Now start tail -f /var/log/audit/audit.log. When the attributes change you will see ...


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 ...


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 )


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.


0

The fat32 filesystem has no notion of ownership or permissions. The man page for mount lists these options that help make it look closer to what Unix users expect: uid=value and gid=value Set the owner and group of all files. (Default: the uid and gid of the current process.) umask=value Set the umask (the bitmask of the permissions ...


0

My guess would be (although I've never done this before, I've always had the nfs mount up first) is that the running user didn't have access until it was reloaded - either it didn't know about it or something along those lines. Never tried this before though so I'm not really sure


0

The only time I have seen this kind of scenario is when the NFS share is exported from a Windows server running NFS for Windows services. The POSIX attributes demanded by the Unix/Linux world aren't mapped cleanly onto the NTFS attributes and the result is that permissions display one thing and (sometimes) act as another. In our particular situation we ...


-1

If the sticky bit chmod +s is set on the folder, the umask is overridden with the attributes of the folder owner. that is why you may be seeing inconsistent results between folders.


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


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 ...


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 ...


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 ...


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 ...


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 ...


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 ...


1

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


1

The good news is that all your data is still there. The mixed news is that your system installation may or may not be recoverable — it depends where chmod stopped. You will need to boot into a rescue system to repair it. From the rescue system, mount your broken installation somewhere, say /mnt. Issue the following commands: chmod 755 /mnt find /mnt -type ...


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 ...


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 ...


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.


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 ...


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, ...


1

The setfacl manual page explains who can grant privileges: The file owner and processes capable of CAP_FOWNER are granted the right to modify ACLs of a file. This is analogous to the permissions required for accessing the file mode. (On current Linux systems, root is the only user with the CAP_FOWNER capability.) So fred can only use setfacl on files ...


0

Sometimes in a fresh day you see things differently... I've added all users to group vboxsf. Not that I find the solution particularly elegant (I'd accept a better answer if somebody posts it). But it works and I don't quite see the harm on it. There were two users in the vm beside oracle, their ids are: davfs2and dm. No idea what's their use.


1

When you change a file's metadata (permissions, ownership, timestamps, …), you aren't changing the directory, you're changing the file's inode. This requires the x permission on the directory (to access the file), and ownership of the file (only the user who owns the file can change its permissions). I think this is intuitive if you remember that files can ...



Top 50 recent answers are included