Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I recently ran into a permission problem wherein a user, belonging to the group owning the files, was not able to write. Since the write operation the user wanted to perform was a complicated Git command it was not a matter of checking one file's permissions. I simply issued
The permission problem still persisted. Digging around I found that a directory
Code:
/home/git/projectX/.git/objects
was not group writable even after issuing the above commands.
Is my understanding of the -R switch wrong? The -R works in other cases on hidden directory and files. Can anyone offer some insight, please and thanks.
If I create a simple directory tree, and in that tree, include a directory starting with dot, chmod -R g+w changes the group write permission just fine, on the system I'm using.
Are you saying that if you look at the permissions on /home/git/projectX/.git/objects the group write bit is not set?
Or are you instead saying that when some complicated Git command is run, there are error messages?
More complete details on the situation would be helpful.
Without them, we can only guess, or try to provide rather general ideas.
Sometimes there can be issues with sudo instead of su.
Some implementations of chmod process symbolic links differently, depending on whether the link was specified on the command line or encountered recursively.
Also, sometimes there can effectively be an interaction between mode bits.
Some implementations of chmod accept a -v option which causes the command to provide a verbose description for every change it makes, or does not make.
If your chmod has that option, you could try that to see if it tells you it will not change the group write bit in some situation.
Some commands run setuid/setgid and so if the issue is error messages from some Git command, or some other command which might be involved in the more complicated situation which you mentioned in passing, then the way in which permissions are being used might be more complicated that you originally expected.
I was running as root, i.e. sudo -s.
After running chmod -R g+w /home/git/projectX the directory /home/git/projectX/.git/objects still did not have the group write bit set.
Git is abstracted from this scenario, it only informed me of permission problems.
Here is the command line output from my problem:
So you can see objects and the contents of objects did not get updated.
Running a clean test, using Kakaka's suggestion of the -v option we have:
Code:
$ sudo -s
# cd /home/obscurious
# mkdir -p tmp/.hidden
# touch tmp/.hidden/testfile
# ls -la tmp/.hidden/testfile
-rw-rw-r-- 1 root root 0 2012-09-12 13:27 testfile
# chmod -Rv g+x tmp
mode of `tmp' changed to 0775 (rwxrwxr-x)
mode of `tmp/.hid' retained as 0775 (rwxrwxr-x)
mode of `tmp/.hid/testfile' changed to 0674 (rw-rwxr--)
# ls -la tmp/.hid
-rw-rw-r-- 1 root root 0 2012-09-12 13:27 testfile
Which worked as expected and did not reproduce the problem described above. I hope this is more clear. This is an up-to-date ubuntu server 12.04, running bash.
I had mentioned that sometimes mode bits effectively interact. Notice the s in the group section of the mode bits from this line of output you posted:
Code:
drwxrwsr-x 8 git git 4.0K 2012-08-27 16:08 .git/
If Git set that bit, then you may need to review Git's security model, because you might be effectively bypassing it by making the changes you are.
Depending on exactly how chmod is implemented in the kernel you are using, you may be able to remove the s by running:
Code:
chmod g-s .git
then if run purely as root ( that is, IF sudo -s in your environment is indeed equivalent to su - ) , the recursive chmod should likely behave as you expected.
But if Git set that bit and the original owner and group owner of the directories in the directory tree, ( possible bugs in Git not withstanding ) the bit probably shouldn't be changed, and the changes you are trying to make probably shouldn't be made.
Another possible command to investigate if there are still problems:
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.