User Created 3 folders in SVN,in that some people have access to all folders.User created another sub folder from folder1 for that particular sub folder he want authorization.
please help on this.
Regards,
Nageswari
You would need to include Path-Based Authorization. You can limit permissions to the folder through the authz file. So let's say you have a directory structure such as:
Repo/trunk
|_ Folder1
|_ Sub-folder
|_ Folder2
|_ Folder3
You would set your permissions file like this:
[groups]
x-group = Nageswari, Chris
y-group = User3
[Repo:/trunk]
#x-group = rw
#y-group = rw
[Repo:/trunk/Folder1/Sub-folder]
#x-group =
#y-group = rw
Where the line #x-group = essentially forbids a certain group (or you can specify a user as well) from accessing that directory. (In all honesty, the line underneath that: #y-group = rw is actually redundant because it would inherently receive those permissions for y-group from the trunk.. But for brevity sake you can keep it in).
Related
I have a Jekyll site and I want to make collections but with subdirectories
For example, I have kind of this structure:
......
_projects/ # "mysite.domain/projects", contains list of available projects (based on these directory)
├── lineageos # "mysite.domain/projects/lineageos"
├── twrp # "mysite.domain/projects/twrp"
└── ungap # "mysite.domain/projects/ungap"
Is there a way to achieve this? I have read the Jekyll collections docs, but I can't understand it all and apply it for this.
Thanks! Let me know if you need more details.
Note: The things that making me confused is config file and markdown/layout structure for this kind of collections. So it will very appreciated if you tell me about this with detail :)
You have to include the projects folder in the _config.yml and set the output to true. The sort_by is optional.
The collection folder must start with underscore _ so rename the folder to "_projects" instead of projects.
collections:
projects:
output: true
sort_by: title
See the hint box of the jekyll docu - collections
Be sure to name your directories correctly
The folder must be named identically to the collection you defined in your _config.yml file, with the addition of the preceding _ character.
I'm setting up a new algorithm and I want to share it on another computer. How can I set paths with only the folder name, for example.
I've tried to use the function os.chdir(path), but I don't achieve to reach my folder when I'm not using a 'root path' like C:/../../folder.
os.chdir(../folder_name)
By doing os.chdir(../folder_name), you are referring to the parent dir of the current directory.
You probably are looking for the os.chdir(./folder_name), with one dot? This is the current directory, where your script stands.
More here: https://learn.microsoft.com/en-us/dotnet/standard/io/file-path-formats
Update: After clarification in the comments, you want to refer to folder_name from one of its subfolder (/folder_name/library). Then it is indeed .. that you should use, but .. only:
os.chdir(..)
When I tried to simulate the permission system under Linux, some strange things came about.
I created a directory 'main' by user 'normal', and created directory 'aha' which permission is 700 using root.
so the owner of 'main' is 'normal', if the permission is 755, I can delete 'aha' just using 'normal' user although its owner is root.
but when i put a file in 'aha', everything is changed. I can not remove 'aha' due to there's still a file in it.
so, my question is, since 'aha' is 700 by root, how can 'normal' know it's empty or not?
My further question is : what does read permission of a directory really mean?
Think of a UNIX directory as a drawer of index cards in the library catalog.
In order to know what books there are, you need read permission on the "drawer". In order to create or remove new "books", you need write permissions (which give you ability to put new cards, or remove existing cards from the drawer). In order to "traverse" the directory to a lower level "sub-drawer", you need execute permission on the drawer itself.
If you already know that book /foo/bar/baz exists, you don't need read permissions on /, /foo or /foo/bar, but you do need execute permissions on all of them.
A given book could be referenced by multiple "cards" in the same or separate "drawer" (that's hard links).
A "card" can reference another card (that's symlinks). Symlinks could became "dangling" (if the other card is removed).
When a book is not referenced by any card in any of the drawers, it "evaporates" from the library.
since 'aha' is 700 by root, how can 'normal' know it's empty or not
Well, one way is to try to remove it. If you succeed, it must have been empty. If it was not empty, "normal" can't find out anymore than that, since "normal" can't read the directory, and therefore can't find how many cards are in that "drawer", or what they are called.
Update:
why do you need execute permissions to traverse a directory.
Because that's the definition of the eXecutable bit for directories. Since you can't reasonably execute a directory, that bit would be wasted otherwise. No, the . and .. files have nothing to to do with the execute bit.
very basically a file/dir permission of 700 is not seven hundred but actually
owner = 7
group = 0
everyone = 0
the numbers pertain to a permission level
0 = no permission
1 = allow to execute (run file or access directory)
2 = allow to write (manipulate)
4 = allow to read (see)
you add the permissions levels up to assign more then one permission for example
$ chmod 754 foo
gives full access to the owner (1+2+4), execute 'n' read to the group (1+4), and read to everyone (4) look at
http://www.linuxclues.com/articles/16.htm
http://www.tuxfiles.org/linuxhelp/filepermissions.html
for more info
I want to make certain folders read-only for the developers while some subfolders in that folder as write also.
For example, consider the folder structure:
Meeting/Jan/DevInfo/
Meeting/Feb/DevInfo/
Meeting/March/DevInfo/
Meeting/April/DevInfo/
Meeting/May/DevInfo/
I want the developers to have read permission to //Meeting/ but write permission to //Meeting/.../DevInfo/...
Can I use the following code?
read group developers * //Meeting/...
write group developers * //Meeting/.../DevInfo/...
I think it should be correct, but visual in P4 shows that the whole structure of //Meeting/ is write-allowed for developers.
Change the write access line to:
write group developers * //Meeting/*/DevInfo/...
The * character means "all files within the Meeting directory, excluding subdirectories".
The ... entry that you had before means "all files and subdirectories under //Meeting", so it overrode the following DevInfo/... section.
Try running the following to check what the protection levels are:
p4 protects //Meeting/...
My system administrators advice me to be careful when setting access control to files and directories. He gave me an example and I got confused, here it is:
a file with protection mode 644 (octal) contained in a directory with protection mode 730.
so it means:
File: 110 100 100 (owner, group, other: rw- r-- r--)
Directory: 111 011 000 (owner, group, other: rwx -wx ---)
How can file be compromised in this case?
It depends on what you mean by 'compromise' and it depends on who belongs to the group.
The directory permissions are critical. Since members of the group can access the directory ('x') and can modify the directory ('w'), even though they cannot list the directory (no 'r'), it means that if a member of the group knows the name of the file, that person can also remove it because removing a file requires permission to write to the directory - the file permissions are immaterial (even though commands such as 'rm' let you know when you don't have write permission on the file, that is a courtesy, because it doesn't matter to the 'unlink()' system call).
So, a member of your group (or, more precisely, a member of the group to which the directory belongs) can remove the file if they know its name. They can also read the file if they know its name, and they can create a file of the same name if the original is already missing. It appears from the file permissions that being able to read the file is not compromise - you would have denied group read access (and public read access) if that mattered.
Note that although your group members cannot modify the file, because they can delete the file and create a new one with the same name, the result is basically the same as being able to modify the file. One key difference is that you'd know which user did the mischief because that user would own the file. (Well, someone with access to that user ID did the mischief.)
Since the directory can be written to, the file could simply be overwritten with another if the attacker is in the directory owner's group.