Is it possible to set different permissions for directories in the same repository?
Can we set permissions on a directory level or only on repository level?
Yes you can, by using Include and Exclude patterns on a Permission Target
Related
I am trying to create folders in Gitlab through the web interface. I was able to see some repositories with folders. I could not find any option to create such folders. How are such folders created?
If you specified a path for a file, Gitlab will create directories if they not exists.
For example, if you add a file named dir1/dir2/test.md, Gitlab create two nested directories with test.md inside.
Noticed this when creating a new directory in unix, and was just curious as to why this is so.
Thanks
A new directory created by a user and owned by the user with full permissions is no big deal. However, a new file/program if executed accidentally or before configuration could have catastrophic results. So the designers decided to give you a layer of protection.
It also prevents other users from executing the file unless you specifically grant permission.
Because you need the executable permissions to naviguate into the directory.
So basic permissions allow user to read file (read file permission), and to access file in directory (directory execute permission).
Note that read permission on a folder allow user to list files in it. (But doesnt allow to read them unless execute permission is granted too as I said in the first place)
Basically, +x on a directory means that the user can 'execute it' hence change into it (replace user by group or other depending on position in permissions).
Hence drwxr--r-- means only user can change into directory. More here.
The directory needs to have executable permissions so you can do things such as cd into it. Also the executable permission lets you look into the directory for inode information of the files it contains.
More info can be found at this source.
I recently switched my development machine from Windows XP to Windows 7 and since that switch, I have a problem with files permissions when I do operations with Tortoise SVN.
Example:
I Have two ASP.NET website set on my local IIS. Beta and Devlo. Beta is a check out of the branch I'm working on and Devlo is a check out of the Trunk.
I made some change on the Beta website and Check it in.
Then I made a merge to reintegrate the branch in the truck on the Devlo website, but I got this error when I test it :
Parser Error
Description: An error occurred during the parsing of a resource required to
service this request. Please review the following specific parse error details
and modify your source file appropriately.
Parser Error Message: Access to the path 'C:\[...]' is denied.
After investigation, I discovered that every file that was modified by the Tortoise SVN merge lost theirs file permission (Read, Read & Execute) for the users IUSE and IIS_IUSRS.
I could manually put them back, but this happen every time I perform an operation of this kind. Is there a way to keep those permissions unchanged by the SVN operation?
Update
Before the Merge, the file was inheriting is permission from the parent folder (has it's supposed to do.)
But not after the merge :
The original file (in the beta folder) was inheriting is permission from the parent folder.
Why the TortoiseSVN (explicitly?) block permission inheritance?
I had the same issue and fixed it with the help of this SO answer: https://stackoverflow.com/a/8993163/361831
The answer mentions that updated files are copied to a .svn/tmp directory which is located in the top level of your working copy (as of tortoiseSVN 1.7). This top level dir didn't have the IIS permissions so I guess they weren't inheriting during the copy. So I just set the IIS permissions to that top level dir and set to inherit, and that fixed the issue.
When subversion updates a file it first creates a temporary version in .svn/tmp/. It then moves the file into the right location. (This to avoid corruptions)
In 1.6 it did this for every directory by itself, but in 1.7 there is just a .svn in the top level directory of your working copy.
If somehow the filesystem permissions of this .svn directory are restricted, it is possible that the restrictions are copied with the file when it is moved in place. (Subversion doesn't change the permissions itself on Windows)
ANSWER: Locate your .svn directory for that project and fix the permissions with permissions needed by your project.
You should be able to set these permissions on the folder that contains the files and then let the files inherit these permissions, instead of explicitly setting the permissions on the files themselves.
TortoiseSVN may delete and create files instead of renaming. When a new file is created this way it will not have the original permissions, but it will inherit permissions from its container.
See also: Explicit vs. Inherited Permissions
Each permission that exists can be assigned one of two ways:
explicitly or by inheritance. For this reason, permissions are
referred to as explicit permissions and inherited permissions.
Explicit permissions are permissions that are set by default when the object is created, or by user action.
Inherited permissions are permissions that are given to an object because it is a child of a parent object.
Similar to the way rights are managed for groups of users, permissions
are best managed for containers of objects. Objects within the
container inherit all the access permissions in that container.
See also: TortoiseSVN - Deleting, Moving and Renaming
Since renames and moves are done as a delete followed by an add...
I had the same problem on both my Win7 64bit machines. I would check in code on one, go to the other, do a Tortoise SVN Update, and have to reset the permissions on the folder to let the parent folder's permissions propagate downwards.
I finally found this article, tried it, and two weeks later it seems to be holding up.
Open the Registry Editor (click Start > Run, type regedit, then press ENTER).
Locate the following registry key:
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer
With the key selected, on the Edit menu, click Add Value, and then add the following registry value:
Value name: ForceCopyAclwithFile
Data type: DWORD
Value data: 1
Exit the Registry Editor.
http://kb.globalscape.com/KnowledgebaseArticle10473.aspx
I recently removed my ACL because my professor needed to copy certain files. Now I know I should have just granted his user permissions instead of removing it all using 'setfacl -b .' on my home directory.
So the question is how do I recover or set a new ACL to my home directory using setfacl/getfacl?
You can't 'recover' what you discarded in the way of ACLs. If you know what you had set previously, you can reinstate those remembered ACLs anew, carefully.
Basic Permissions
On a Unix system, the most important criteria for you are the group and other ones - they are not directly affected by ACLs, but they control the access not governed by ACLs, and you must get them right too. You need to decide what is appropriate in your environment. For many corporate settings, allowing group and others read access on files, execute on programs, and read and search (execute) on directories is appropriate:
chmod 644 file
chmod 755 program
chmod 755 directory
If you are not supposed to let other people borrow your course work, you would nail things down so that group and others are not allowed in at all:
chmod 600 file
chmod 700 program
chmod 700 directory
Or you can mix and match; allow flexibility and open access to your home directory, but restrict people underneath that. In some circumstances, you might allow group or other only execute permission on a directory (and only read on a file). Then other people cannot access the file unless they know its name, and they can only read the file, not modify it or the directory that holds it.
Don't forget to use an appropriate umask setting so files are created with the correct permissions by default. For many people, a umask of 022 is appropriate; neither group members nor others can write to the file or directory, but they can read files or execute programs.
Using ACLs
None of this requires ACLs. If you want to provide controlled access to certain groups or users and not to others, then you need to ensure you have the appropriate base-level permissions set, and you can then effectively add permissions for selected users or groups on the files or directories you choose.
The Solaris 10 man page for setfacl says that the command syntax is:
setfacl [-r] -s acl_entries file
setfacl [-r] -md acl_entries file
setfacl [-r] -f acl_file file
This does not mention the '-b' option mentioned in the question, so you may be using a different platform. Note that the ACL controls was going to be POSIX 1e, but was never actually standardized, so different platforms implement slightly different variants on the commands.
The Solaris 10 man page then goes on to explain how to set the 'acl_entries' part of the description, with a note that the default part can only be applied to a directory, but the default values will be used for files in the directory.
ACL Entry Description
u[ser]::perms File owner permissions.
g[roup]::perms File group owner permissions.
o[ther]:perms Permissions for users other than
the file owner or members of file
group owner.
m[ask]:perms The ACL mask. The mask entry indi-
cates the maximum permissions
allowed for users (other than the
owner) and for groups. The mask is
a quick way to change permissions
on all the users and groups.
u[ser]:uid:perms Permissions for a specific user.
For uid, you can specify either a
user name or a numeric UID.
g[roup]:gid:perms Permissions for a specific group.
For gid, you can specify either a
group name or a numeric GID.
d[efault]:u[ser]::perms Default file owner permissions.
d[efault]:g[roup]::perms Default file group owner permis-
sions.
d[efault]:o[ther]:perms Default permissions for users other
than the file owner or members of
the file group owner.
d[efault]:m[ask]:perms Default ACL mask.
d[efault]:u[ser]:uid:perms Default permissions for a specific
user. For uid, you can specify
either a user name or a numeric
UID.
d[efault]:g[roup]:gid:perms Default permissions for a specific
group. For gid, you can specify
either a group name or a numeric
GID.
You will need to decide who, apart from your professor, needs access to files. Maybe your lab partner does; maybe the teaching assistants do; maybe your whole year (but not the years below you - those above you probably already know what you know). But without any more information about your requirements for protection, no-one can help you more. And generally, it is easy to get the ACLs wrong - use sparingly, if at all, and use the standard Unix permissions as your main access control.
And next time, I suggest simply allowing your professor in by adding (not erasing) ACLs - or asking him where he wants you to copy the files to (putting the onus on him to sort out the permissions issues), or copying the files into a directory such as $HOME/tmp/prof.jones with 711 permission on the directory, 644 permissions on the files, and tell him which files are there for him to copy.
How do I grant access to on an NTFS folder (Win2003) such that when files are added to this folder, they get the same access permissions? My problem is that I have granted read access to the 'network service' on a specific folder but when I add files to that folder (programatically generate the files to this folder), the network service does not have read access to these files. I would have thought that the permissions cascade to the files in the folder? Any help is highly appreciated.
Are the child objects in the folder inheriting permissions from the parent? Right-click the folder-properties-permissions-advanced.
And are you moving (as opposed to copying) the files in the folder? Move files also moves their permissions.