Closed (won't fix)
Project:
Node access user reference
Version:
7.x-3.x-dev
Component:
Code
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
12 Oct 2011 at 10:55 UTC
Updated:
17 Mar 2016 at 00:43 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
pfrenssenComment #2
danielb commentedFile permissions?
Huh?
Can you give more information?
Comment #3
danielb commentedI can't find any info that you can keep permissions on a file after transferring it, zipping it, emailing it, etc... ?
Plus when I look in my copy of the module directory on my server; it is already 644.
Comment #4
danielb commentedTo me that suggests the file is already 644?
Not that I think it matters. Isn't this really up to the person installing the module? Any docs that say otherwise?
Comment #5
pfrenssenIn the git repository the permissions are not correct. If I check out the latest repository and look at the files I see that the files in the root folder are executable.
I'll have a look in the documentation about the guidelines.
Comment #6
pfrenssenI can't find an explicit mention in the documentation, but it seems like common sense to make files non-executable and directories executable.
I asked on IRC and xjm pointed me to this issue: #1113148: File permissions inside a git repository
Comment #7
pfrenssenComment #8
danielb commentedI don't see evidence of this. What you've shown is what the files look like on your server/computer.
I also asked on IRC and they said not to worry about this issue.
Comment #9
danielb commentedWell since it's an easy commit, I'll commit it.
I'm curious if this does actually make a difference on your end?
Comment #10
danielb commentedI've committed it.
I don't know what good it will do if this is a real issue, since if something caused this in the first place it is bound to happen again. I use windows to develop and commit, etc.. so who knows.
Installing the current(old) version of the module on a unix setup gives me 644 everytime.
Comment #11
pfrenssenOuch I think you accidentally committed the patch from #1305886: Extend documentation.
It is indeed because I work with linux that I have noticed this issue in the first place. All executable files are highlighted in a very bold colour, so they stood out when I browsed through the module files.
Anyway thanks for the great module and your patience!
Comment #12
danielb commentedlol woops
Comment #13
danielb commentedI don't think that's what happened, Readme looks the same as it did before :/
I'll try again
Comment #14
danielb commentedI must have done it right because if I apply the patch now it says "nothing to commit".
I think the real answer is that this file permissions thing isn't commit-able.
Comment #15
danielb commentedhttp://drupalcode.org/project/nodeaccess_userreference.git/commitdiff/a7...
I'm guessing this is why you thought it was the patch from the other issue. Looks like all that changed is \r\n linebreaks got changed to \n, which must have been an incidental thing that happened from dealing with the other issue - I must have saved it in unix format, which is still a bonus.
It might be that I can't commit your permissions patch because I'm running gitbash in windows, and applying the patch with file permissions might not actually affect the file?
Comment #16
pfrenssenI suppose the actual danger is rather limited. If an attacker has sufficient permissions to inject malicious code in these files there are probably other more important security holes to worry about.
If you ever get your hands on a linux or OSX machine it would be nice if you could commit it after all, I suppose it does not work on Windows because it handles permissions differently than *nix. When I try it here on the latest dev it works without a hitch:
Comment #17
danielb commentedhttps://www.drupal.org/node/1988384