I have a user 'git' that owns a git repository. I'm trying to setup a post-update hook that copies the files in the repository to /var/www/site/. I'm still getting a hang of users and permissions in linux, what is the best scheme for this situation?
You could either have git own /var/www/site/, and give it 660 permissions on it (read and write, no execute), or make /var/www/site/ world writeable (which is not entirely a good idea, as then any user can copy, edit, etc. files in /var/www/site/). chown could help you change the owner, and chmod can help you change file permissions.
You can also add git to the group who owns /var/www/site/, and make sure that the group has read/write permissions on /var/www/site/ as well.
And if you ever need help with chown, chmod, or any other linux command, man can help you out.
Related
I am looking at building a script, which eventually needs to install some application - copying folders/files to certain places in Mac & Linux. User should not be able to delete those folders/files or the script i pass to user. Is there any way to achive this?
For mac - sudo chflags schg /path/to/file - can be set.
For Linux - i can set sticky bit via chmod +s /path/to/file.
Problem is, if the user knows administrator password ( root password i meant), then they can change the permissions and then delete using rm -rf.
Question is how do i catch them? How do i make sure, if in case user as root runs rm -rf, its catched, and my files/folders does not get deleted.
Any pointers to this are greatly helpful.
Thanks
EDITED:
Due to a clarifying note by the OP, the purpose here is to control network users who somehow got the root password, rather than subvert the will of the lawful owner of the machine.
You cannot do what you're trying to do, nor should you.
If the user has the root password, it means you trust her with the computer. If you want someone not to be able to do something, don't give them the root password.
The attributes you mention are good ways to prevent accidental deletion of files, and it is all you can expect to achieve.
Again, if you want them not to delete the files, don't give them root.
On my school directory when I ls -l (running Fedora) I see that I have a ton of files and directories owned by me, but one specific directory is owned by someone else. I recall a few months ago I tried copying that directory to my own as it had 744 privileges by that user. For some reason that user owns the directory in my home directory with 700 privileges so I cannot delete the directory. My home directory has 700 privileges.
Anyone know why something like this could have happened and how I can prevent it form happening in the future? Also, how should I go about deleting these files in my home directory? If needed I can contact IT but I want to see if there is anything I can do without contacting them.
Yellow is my user, red is the foreign user
Two possible options IMHO:
Check the permissions of your /home/YELLOW folder, if it
has o+w, or g+w, someone (the user
listed as the owner of the directory) may have created it there.
root did it. It doesn't make much sense for you, so probably if he/she did, it was by mistake (for example, performing some backup-and-restore administration and so on).
Normally permission for deletion of things in unix filesytems are grabbed from
the parent folder, so, you need to have "write permission" in a folder
to create or remove files (unless there is sticky bit in action);
directories are just special type of files so the rules still applies.
If the directory is empty, a simple rmdir p2Testing or rm -rf p2Testing would be enough. But, if the directory has files and
sub-directories, you won't have permissions to modify or delete them
(look at the drwx------), and only someone with more powers will be
able to do it for you (e.g. root, or the owner if he still have +w in
/home/YELLOW).
When I install Cygwin, the default location is c:\cygwin and after I open a Cygwin terminal, it creates my home folder in C:\cygwin\home\ which the Everyone group has read access to by default. So, if I create a diary in vim and save it to my profile, all users of the computer I'm logged on to can read my diary. Obviously this is not the default option for normal Windows profiles, so I'm wondering what the logic is behind Cygwin's default home directory permissions, so I can use it the way it is meant to be used. Thanks!
There are differences between the permission structures of windows and cygwin.
You can protect your diary by specifying its permission in windows using right click.
You can then check its permissions in cygwin using:
ls -l diary.txt
chmod 0600 diary.txt
ls -l diary.txt
Then login the same machine as a different (test) user and see if you read the file under windows, and in cygwin.
For people interested in this topic, it probably goes back to a setting called UMASK on linux, which specifies default permissions for new files. The default value of "022" means "take away no permissions from the owner, and take away write permissions from the group and the rest of the world" which means that file owners have full access, everyone else has read access.
They say it's to make it easier to share files with other users. I say it's obvious that this logic predates times when we had web browsers and other tools capable of saving passwords to disk.
Is there any way to say to GIT to stop copying file group and owner settings? My situation is as followed:
I am developing on home server where I need to use my users permissions (not root) in order to develop in Eclipse IDE (Eclipse crying if files are in root owner and group as it cannot work with them).
Once I am done, I am using GIT to synchronize with remote server which is running on Red Hat and file/folders groups and owners are server specific. However when I will synchronize it will copy my home servers permissions as well and apache on remote server throwing errors as it cannot read files so I need to reset it myself after every commit on new/changed files.
Any thoughts how to change my workflow?
P.S: I am using Linux/Debian on home server
Check the answer here: How do you deal with file ownership in git?
You're not doing anything wrong, this is just basic git behavior. You can change the permissions locally to what they need to be on the server and do a new commit. Or you can create a script to fix all of the ownerships/permissions on the server when you do your sync.
If you are using a git push to push the changes to your server via a git repository on the server, you can create a post-receive hook to call this script.
http://git-scm.com/book/en/Customizing-Git-Git-Hooks
One other thing did occur to me. A lot of Linux distros set the default umask as 0077 or 0007. Since I'm the only one using my laptop, I changed mine to 0002 since it just makes many things easier (plus my home directory is still 700). So all files I create will be rwxrwxr-x. Changing your umask would keep you from needing to think about setting the permissions later.
I found my answer to my question after a while and though I will answer just for the record.
User/group ownership is not shared (and therefore stored) through the repository. Only numeric file permissions are transferred (e.g. 644).
The file which is updated/created will adapt user and group ownership from the current user that is running Git commands.
I run servers on my Linux Server (Ubuntu) and there's a bit of a problem. It may seem simple to fix, however I don't think it is. The servers run in my username (server), however, others access certain files with different users via FTP. Because the server is running in my username, whenever a plugin creates new files, they do not have permission to edit etc.
I have tried putting the users into groups and then allowing group access to that folder (even for new files), but had no luck. Every time they need to edit the files, I need to chmod -R 777 it.
I thought about running the servers in their usernames, however that would produce complications. Is it actually possible to make new files retain the permissions of the parent (or a top folder)? All the solutions I've found doesn't seem to work.
Not for users but for groups. You can:
chmod g+s parent_dir
chgrp shared_group parent_dir
If you create files inside it, that files will have the group of the folder (shared_group).