I'm stuck into something complex which makes me think that this scenario is not possible. Anyway here's the scenario:
Say my directory structure is like this:
/var/www/dir1/dir2/dir3
/var is owned by root
/var/www/dir1/ is owned by group1
/var/www/dir1/dir2 is owned by group2
the problem i have is that i want to allow dir2/ group users to have only access to this directory and I don't want them to have access to the upper directories.
I tried changing the chmod of dir1/ to 711 but it then restricts the group2 users.
Is there any way to allow group2 users access the dir2/ but not any parent directories?
If so, please explain.
Waiting for response..
Thank you!
As indicated in the comments:
You are looking for chroot. See for example this cyberciti.biz/tips/howto-linux-unix-rssh-chroot-jail-setup.html to get a basic idea of it
Then we commented:
According to my understanding, I'll have to change many things like
copying directories and stuff but I wanted to give access to the group
only to a specific directory and nothing else. Is chroot the only
solution for it?
And my view is that if you want them to be jailed in that specific directory, yes. Otherwise they will be able to go through other dirs.
Hope it helps!
Related
I have an AppArmor profile. I have dir like
/home
/nonroot
/Documents
/Pictures
.
.
.
Now I want to allow only /nonroot path and deny rest of the path in the /home dir. How can I do that? Note that I have to make it generic as I don't know how many sub-dirs I may have inside the /home.
What you want is in fact the normal behavior of AppArmor. That is, /home/nonroot/file.txt r, allows reading just that file and nothing else. If you don't give permission to read Documents, Pictures, etc, then the program cannot access those.
(This is as long as you are actually enforcing the profile. Profiles can be disabled or put into complain or audit mode, which perhaps could confuse someone about how their rules are working)
You know, you start creating a distribution called something.good and on it you define a permissions.zcml with something like:
<configure xmlns="http://namespaces.zope.org/zope">
<permission
id="something.good.reset"
title="something.good: reset entries"
/>
</configure>
But then, once the distribution is installed on the server, you realize that the permission is not good enough and has to be completely refactored to something.else.
Uninstalling something.good from plone_quickinstaller does not remove the permission. Going to any security tab within ZMI you can still see it.
I looked around for documentation, browsing code in AccessControl and Products.GenericSetup but couldn't find anything.
Any idea on how to remove it?
Ok, so Plone is easy, don't mind what others may tell you.
So, you (actually I) want to remove a permission definition? Just do it!
So the list of things to check to properly remove a permission are:
remove the permission from permissions.zcml
if there are no permissions left remove any reference to that file (maybe on your configure.zcml)
remove all references to the permission on profiles/default/rolemap.xml
scan all your configure.zcml or python files (if using grok-like permissions) to references to that permission
And that's it!
Once you restart your instance the permission will no longer show up on ZMI's Security tab.
Seems that permissions are created on-the-fly at startup time? Seems so to me. Prove me wrong though!
Sometimes it is not clear what username a certain gitolite user has. If people want to control access rights for their wild repos, they need to know the usernames. One obvious solution would be to ask them for their usernames.
In our environment the most common case is that the admin is asked for usernames, since sometimes the users themselves do not know their usernames.
This is a bit inconvenient and I would like to know whether is an easy solution, e.g. a command that displays all available usernames. If not, are there any suggestions on how to write such a script and how to access it?
I think what he wanted was a way to list the user names assigned to other users. His concern may be that the admin may have typo-ed the name when adding the pubkey file. Say I send him my "id_rsa.pub". He stores it as "sitram.pub" instead of "sitaram.pub". As long as rights in the conf file are also similarly mis-spelled, you may not even realise this.
The person who wants to give access to his repos has only one choice: ask each of the people he wants to give access to run 'ssh git#host info' and report what username they see.
Partly it's a matter of information disclosure to allow a non-admin user to query all other usernames.
The other part is, if you're in HTTP mode or something, there really is no sane way to know who all the possible authenticated (authenticatable!) users are. For ssh you could of course do something like this:
perl -lne 'print $1 if /-shell (.*?)"/' < ~/.ssh/authorized_keys
Gitolite has a "list-users" command but that only knows the users who are already named in some access rule in the conf file. Which is not quite the same thing.
I added a new command 'usernames' that simply prints a text file that contains all usernames with respective real names. I put this file in the main directory of the gitolite-admin-repo. Only drawback is that this file requires manual updating after a new user is added.
Put this in ~/gitolite-source/src/commands/usernames:
#! /bin/bash
cat $HOME/.gitolite/usernames.txt
Gitolite (V3) has a list of commands, including
ssh git#host info -h
ssh git#host perms -h
Which can help getting to the content of the gitolite config.
ssh git#host perms -l <repo>
Will list the current contents of the permissions file.
This is what I am using
perl -le 'while(<>) {$h{$1}=1 if /-shell (.*?)"/};foreach (sort(keys(%h))){print $_;}' < ~/.ssh/authorized_keys
It is much the same as Sitaram's provided snippet, except it removes duplicates and sorts.
I have a section of my content tree which I would like to deny ALL permissions to except for specific roles. This seems like a really obvious task to perform, and yet I don't see an example of it in the Security Administrator's Cookbook and I can't figure out an easy way to do it using the security tools. I must be missing something obvious... ???
Say I have this:
sitecore
-content
-branchA
-branchB
Everything I created in the content tree is readable by extranet\Anonymous by default. But even when I click on the "Require Login" on the security ribbon, all users still have read access, they just have to log in. I want to make branchB readable by ONLY sitecore\SomeRole members. How is this done?
Ok, follow this guideline.
Let's say we have sitecore\SomeRole and a content tree like this:
Home
branchA
itemA1
branchB
itemB1
We'd like to deny acccess to branchB and all its descendants for everyone, except for SomeRole.
First off, in Security Editor select Home node, choose sitecore\Everyone role and set the following permissions:
alt text http://img822.imageshack.us/img822/7172/sitecoreeveryonepermiss.png
Now check the access in AccessViewer - that's what we need:
alt text http://img532.imageshack.us/img532/3512/sitecoreeveryoneaccess.png
Let's allow branchB for SomeRole. Go back to Security Editor and explicitly allow permissions for SomeRole:
alt text http://img80.imageshack.us/img80/120/sitecoresomerolepermiss.png
And check this in AccessViewer again:
alt text http://img27.imageshack.us/img27/9584/sitecoresomeroleaccess.png
Hope this answers your question. Beware that Sitecore versions prior to 6.2.X have an issue: AccessViewer doesn't refresh correctly after permissions are set. Kill aspnetwp (w3wp) to fix this.
It sounds like your problem is that you're allowing the extranet\Anonymous user to have read access too far up in the tree. Remove the access grant at the top level (don't deny it, just remove it) and grant it wherever you really need it (like at branchA).
Currently after I create a release branch, but when we have some time before we release, I sometimes open the entire branch for edit and then lock all files in order to prevent anybody from modifying anything during "code-freeze" period in the release branch.
Is there a better way? Doing it my current way seems possibly like an incorrect use of the lock feature, is there a better way to keep somebody from checking in code without using branches. I though of P4 protect but I am not the admin on this perforce instance, and also dealing with the protect file at potentially 100s of lines would get cumbersome as well.
Any ideas?
I'm doing this all the time as a builds engineer. I use 'p4 protect' to restrict everyone's access to the trees to read-only:
super group everyone * -//depot/project/branch/...
read group everyone * //depot/project/branch/...
super user me * //depot/project/branch/...
The first line closes all permissions for all users to the branch (assuming that the group 'everyone' is defined properly.)
The second line re-establishes read permissions for everyone.
The last line re-establishes all permissions to just me.
The way to do this in modern Perforce is to use streams -- named branches that update in place on your local system, and can have permissions applied to encourage you to do the right thing when merging and copying between streams.
You can optionally restrict a stream so only the stream owner can check in (and you can lock the stream so no one but the owner can edit its properties). See http://www.perforce.com/perforce/doc.current/manuals/p4guide/chapter.codelines.html#codelines.streams
p4 protect is definitely the better way to go - it's what it is there for. I would strongly recommend you put all your users into groups, and only ever use groups in your protections table - much easier to manage.
You can protect at any level of granularity you like, so is not unwieldy. Note also that the 2008.1 server release has a new protect feature that allows you to specify what you can do in a slightly different way. Change note:
#152278 **
'p4 protect' now allows specification of permission 'rights'.
Previously, 'p4 protect' only allowed using permission levels
which include the specified access (ie 'read') and also all
of its lesser permissions (ie 'read' = 'read' + 'list').
Permission rights make it possible to deny individual rights
without having to re-grant lesser rights. The new
permission rights are '=read', '=branch', '=open',
and '=write'. This functionality was previously undocumented,
and is now fully supported for 2008.1
If you really have an issue with having to be an admin to lock & unlock this, then you should take a look at the "group owner" feature introduced in 2007.3. This will let a non-super user to be able to add & remove people from a group. So combine that with the protections table. I.e. get site admin to set up the protections table, and restrict rights to a group named "Rel 1.0 Authorised", and make you the group owner. You can then add and remove users (or subgroups) from that group to control access.
The trigger option is a possibility, but you still need to be an admin to set up the trigger in the first place. You could also affect performance of all submissions, which is something to look out for. But the main issue with triggers is that you would be using them to emulate a built in feature designed for that purpose - i.e. protections table. And, if you wanted to be safe, you would still need to find some way of preventing anyone else modifying the reference file. It just seems like a lot of work to emulate an existing feature.
As a slight addition to one of the other answers. First set up a group "everyone" which has all users in it. Then add this to p4 protect
write group everyone * -//depot/project/1.0/...
read group everyone * //depot/project/1.0/...
write group 1.0 * //depot/project/1.0/...
This will allow you to create a group "1.0" into which you can add any users who are allowed write access.
If you are using server 2008.1 you can do this.
=write group everyone * -//depot/project/1.0/...
write group 1.0 * //depot/project/1.0/...
The first line removes only the write access ( not read and list ) from the group everyone.
P4 protect is probably the right answer for most people as explained in other answers.
However in my organization I can't be the admin so way of doing this is to have a trigger script in perforce that reads a text file that non-admins have write access to and check whether branch appears on the list.
This way admin access like p4 protect would need is not needed.