Need to change permissions on *nix system to 777 - linux

Have a folder and files as follows:
Folder:
drwxrwxrwx 3 me 153157 8 Aug 17 14:17 Nugget
File within Nugget:
...
-rw-rw-r-- 1 web web 24 Aug 17 14:17 nugget.php
I need to change permissions on nugget.php to 777 as per the documentation.
$ chmod 777 nugget.php
chmod: nugget.php: Operation not permitted
Suggestions?

You could do this as root but I suggest to sit back and think about it for a moment. Anyone with access to your computer will be able to change this file in any way. Crackers get paid money to find files like that and abuse them.
Usually, your problem is that the web app needs to read the file and some user needs to be able to write it. In this case, chown the file to the user and leave the group as web and set the permissions to 640 (local user can read+write, web can only read).

Unless you are in group web, you do not have permissions to write that file. If you own the system, you can use sudo to accomplish what you need. However, if you had sudo access, you probably wouldn't be asking.
Since you own the directory, you can delete the file. So one workaround would be: save the text of the file somewhere else (in another window). Delete the file. Recreate the file in an editor, pasting in the text. Save. That should do it. However, it's possible since this is a script that doing this would break the script (it might need to run as user 'web').
The safest alternative is to ask the system administrator to add you to the group "web", or else to have him or her change the group of the file to a group that you are in.

Your account (the one you logged in as) does not seem to have permissions on that file.
It's owned by "web", and you're not logged in as that user or that group. The permissions on that file for accounts that are not the owner or that do not belong to the web group are listed as "r--", which means the account that you logged in as can only read it.
So, login as root or "web" and perform the same operations.

sudo chmod 777 nugget.php ??

Related

Permissions issue in Linux with root vs other admin acct

I know there are many different examples on here, but I am having trouble with my specific example.
I am trying to copy some files from a specific folder on my Windows PC to my VPS (Virtual Private Server) by using SSH via WinSCP.
The folder that was created looks like this:
As you can see there are permissions as root as the owner. I login as a different user named Smith. When I try to transfer files from the PC to the folder, I get access denied.
A few things I tried:
I deactivated root for security purposes so I can't easily login as root. I could reactivate it temporarily to do this exercise, but trying to find a different way.
Even though Smith is an Admin, that account can't seem to move files to this directory when logging in
I tried sudo -i for root but root doesn't share any groups with Smith and not sure what to do other than making it 777
I know I can just blow out security and make it 777, but I am guessing that's bad practice?
Maybe I missed something in what I did above, but what's the best way so that Smith can copy files to the directory above when logged in as Smith, even though there are no groups shared with root that could be used right now, and I don't want to just blow security wide open?
If you only want to write the directory as the user Smith, then the simplest solution is probably to make Smith the owner of the directory. Assuming you can login to a Linux console with sudo permissions, you can deploy that using a command something like:
$ sudo chown Smith bookstore

Set permission to create a folder that contains a website

I am creating a folder to have my website in it. How do I add permission to create this folder?
MKDIR 777 MyWebSite
Will give Rear, Write & eXecute access to everyone.
So what is the best set of permission that i should use when creating this folder ?
Best is 755 for everything (dirs) 644 for files. Some directories (like uploads in WordPress) need to have 777 as any user can send file there. But that BIG permission should be set only for such directory not for everything. Normally READ for files and execute for dirs (with read) would be enought for almost any directory and file (only that upload dirs needs more).
For a web document root, the best permissions are 755 for directories/folders & 644 for files. The key is making sure the directories/folders as well as the files are owned by the same user connected to the web server. Which in Linux systems is usually www-data. I actually gave a fairly detailed explanation on why 777 permissions are not good for any reason over here and here is an edited version for your question.
When you set permissions to 777 it means that 100% anyone with access to your machine on any level can read, write & execute the file. Meaning if your site gets hacked, a hacker than then use the execute permissions to launch scripts to get deeper in your system. Or someone else on the system—since they can read, write & execute the file—can simply delete your files without you ever knowing.
Setting directories to 755 and setting files to 644 is the best way to go as long as the ownership of the file is solid & correct. 644 permissions basically break down as follows:
The first 6 means the owner of the file can read & write to it.
The next 4 means members of the group connected to that file can only read it.
The next 4 means others—who are neither the owner or a member of the group—can read it.
As for 755 they are best for directories/folders because directories/folders need to have execute rights to allow you to view the contents inside of them. So it breaks down like this:
The first 7 means the owner of the file can read, write & execute it.
The next 5 means members of the group connected to that directory/folder can only read & execute it.
The next 5 means others—who are neither the owner or a member of the group—can can only read & execute it.

Display file / directory permission for all users in Linux

In Linux, It is easy to display file permissions for directories and files for the currently logged-in user from the console.
But can I display the permissions for another user, and any user and any group?
Like something similar to what in Windows is displayed in the "Security" tab in the property window for a file or directory, i.e. it is listing each user which has any rights to that file and what rights he has or doesn't have:
Example of what could be desired output:
/etc/multifile
-rwx------- admin1
-rwx------- admin2
-r--------- john
I have been searching in vain for something like that in Linux. Can you even assign rights to multiple users?
Or does that then exceed the abilities of the "Unix permissions" and it's time to go into ACLs and this sort of thing?
display files with its permissions
stat -c '%a - %n' directory/*
The permissions you see would be the same thing visible to all users.
And the file's permissions are also dependent on the parent directory's permissions.
You can list a file only if the parent directory has both read and execute permission bits for your user or group.
You can view the file only if the parent directory has a write permission bit for your user or group.
And yes the permission bit in others apply to all users.
If you can reorganize your users and groups correctly, you should be able to achieve most of the file permission and access control that you're looking for.
Read more about each of the permission bits here: http://www.tuxfiles.org/linuxhelp/filepermissions.html
Normally there no other permissions to see than the ones you see with
ls -l .
However in some special cases there might be some extra information not shown with the
ls command.
If ls -l shows a plus after the attributes like this:
-rw-r--r--+ 1 tusk tusk 202 2012-03-04 19:31 sfc.txt
Then try getfacl <file> to see the rest of the permission.

WordPress unzip_file() results in mkdir_failed (permissions)

I am creating a WordPress framework that has an auto update facility. When the system updates the framework, it downloads a .zip file (works ok, stored in a temp folder), and afterwards tries to extract that zip file to a place within the theme. When unzipping, it throws an error complaining about not being able to create a directory ("mkdir_failed").
The parent of target folder has permission "775" for user "bitnami" and group "bitnami";
root#linux:/home/bitnami# ls -al /opt/bitnami/apps/wordpress/htdocs/wp-content/themes/nexus
...
drwxrwxr-x 6 bitnami bitnami 4096 Oct 23 14:02 nexusframework
...
And I tried to put the "daemon" user in the "bitnami" group;
usermod -a -G bitnami daemon
Which indeed is assigned correctly I would say, as i see:
root#linux:/home/bitnami# id daemon
uid=1(daemon) gid=1(daemon) groups=1(daemon),1000(bitnami)
So; if the "daemon" user is in the "bitnami" group and the folder has 775 access rights, then why does it fail with "mkdir_failed"?
(note; assigning "777" to the parent folder solves the problem, but this is not an option because of security).
Thanks!
- Gert-Jan
update;
After doing more investigation on Linux in general, I read that Linux automatically creates a 'private' group for each user (so bitnami group for the bitnami user, etc.). I don't know if the problem is caused by the fact that I was trying (and apparently succeeded?) to add other users to the same group or not.
update;
See my answer below on how I resolved my issue.
Ok, thanks for all the comments. I eventually decided not to continu my investigation but to head for another direction, as having to rely on the container's folder to have "775" permission would be unwise for the framework (many clients would have 755 instead, so getting this to work for a group is nice but would eventually not solve my problem).
Instead I further investigated how WordPress themselves download and unzip themes and decided to follow that route.
The key problem i was trying to tackle, was to not have the unzipped files be owned by the 'daemon' user, but by the 'bitnami' user. The reason why it "impersonated" to the daemon user, was because i manually told the code to use the "direct" fs_method (as it appears, WP offers various ways to interact with the filesystem, where the easiest one is 'direct', see here). However, using the 'direct' FS_METHOD is the core reason why I have this problem, as that one will use the credentials of the webserver (the 'daemon' user in my case). So by using a different FS_METHOD, I know am able to unzip the files in the folder, using the correct 'bitnami' user (since the container is owner and has permissions (775, or 755 wouldn't matter) now my problem is solved. Note that instead of writing directly to the filesystem, now PHP will use FTP (see here).
Does it work if you change the group of the folder to daemon?
chgrp -R daemon /opt/bitnami/apps/wordpress/htdocs/wp-content/themes/nexus

ubuntu: share a folder to be used by all user in group

I want to share a folder among all users of a group : dev. So that all files are regardless of the owner can be edited by anyone in the group.
I have created the shared folder and set the respective permissions to the folder.
When a user creates a new file in that folder it belongs to owner:dev
But the permission for the files are rw-r--r--
So other users who belong the same group are not able to edit the files.
Like default group become "dev" how can I set the default permission for the files created in that directory.
I don't want to use "umask" technique because the user will upload files into that directory throuh ftp and other tools.
This really belongs on serverfault and I already mentioned there's almost an exact duplicate there, but anyway there's a nice little solution you can use, which is the FUSE bindfs module (there's a package in ubuntu). You use it to mount one directory onto another mountpoint and can set things such as the default permissions of any files created here, their owner, group and the permissions of files already in the directory (which is what you seem to want).
I don't want to use "umask" technique because the user will upload files into that directory throuh ftp and other tools.
That's the only way to do it, unless those "other tools" are themselves able to adjust permissions.
If you have root access, you can set the default umask for everyone to 002 from /etc/bashrc (assuming bash the default shell for the users in question).
A hack (and this is less preferable to umask) is to setup a cron job that will run every minute and do a chmod -R g+w <dir>.

Resources