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.
Related
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!
I am trying to programmatic-ally set the Gnome 3/GDM 3 user profile/tile/face picture for a user's account in Gnome3/GDM. This is my first attempt at a simple program for Linux and I'm unfamiliar with the APIs and my searching has yielded little useful information. It seems like one can write data to a .face file but this doesn't seem to take affect (or perhaps my file type/specs are wrong). I found from this forum post that the information is stored in a user-specific directory under /var/lib/AccountsService/users, however I want my program to run with regular user privileges and writing (directly) to this file would require elevated privileges (despite an unprivileged user being able to specify an image for their account via the Gnome settings GUI).
Ideally, I would like to do the same for KDE/KDM and Gnome 2 versions as well. Any information would be greatly appreciated. Thanks!
OK, here's the part I can shed some light on:
On any Unix'y OS, you can always fall back on the GECOS field update function putpwent. Traditionally, the “Real Name” is the first part of the GECOS field in the user record, up to the first ,. Different systems store different extended information after the ,, including things like department names, home and office phone numbers and the like.
In Gnome 2, “they” used to use ~/.face as your personal face icon. However, there are all kinds of situations in which one user can't look into another's home folder (including root: things like network filesystems, encrypted loopback homes, and more), so this was abandoned at some point (I believe 3.0) in favour of the /var/lib/AccountsService/icons/$YOURNAMEHERE location.
In the spirit of Gnome 3, the new system (the one you most likely want to use) is the Accounts Services DBus service. You can obtain a user object over DBus, and alter it. The interface is org.freedesktop.Accounts / org.freedesktop.Accounts.User and has methods like SetRealName and SetIconFile. There are also a “bunch” of other methods for things like location, language, eMail, …
PS: you can also use libaccountsservice to interact with it without calling the DBus yourself. EG: void act_user_set_real_name (ActUser *user,
const char *real_name) and void act_user_set_icon_file (ActUser *user,
const char *icon_file) are exported from that library.
However, I don't know if K (or which version(s) of K) might be looking at this DBus service. So, if you really want to set up the K information, I'm afraid I don't know…
For what it's worth, you can also just let the user adjust it themself with
gnome-control-center user-accounts
I had originally asked the original, closely-related question on superuser.com, but I feel this might be a little more stackoverflow speed since I want something programmatic and automated, using tools no one there knows well. Here is the scenario:
Two accounts:
Account A (original work account with
quota)
Account B (new backup email
account)
Process:
Create folder in Account B (e.g. "2010 Email Backup" folder).
Migrate all folders in Account A nested into new folder on Account B (e.g. "2010 Email Backup" -> "Inbox", "Sent", "Trash", etc.).
I want to be able to do this every couple of months or every year, and script it for my needs with either imapsync or offlineimap. So: will using these tools, if this is possible, cause an issue when it checks Account A and clears out Account B because the original folders are different? I am not sure how specific they are, so I wanted some reports from the field. If anyone has experience with these tools, PLEASE let me know. I would love to figure this out before I hit a quota.
From the imapsync FAQ:
Q. I have moved from Braunschweig to Graz, so I would like to have my
whole Braunschweig mail sorted into a folder INBOX.Braunschweig of my
new mail account.
R.
1) First try (safe mode):
imapsync \
...
--regextrans2 's/INBOX(.*)/INBOX.Braunschweig$1/' \
--dry --justfolders
2) See if the output says everything you want imapsync to do,
--dry option is safe and does nothing real.
3) Remove --dry.
Check the imap folder tree on the target side.
4) Remove --justfolders.
Good tip, never realized you could use --dry or pick another folder with --regextrans2
Could of been possible with:
--prefix1 INBOX.Braunschweig
You might also want to use --subscribe to make sure that you don't have any folders your not subscribed to that could otherwise get missed.
We actually wrote a cPanel IMAPSYNC too.
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.