How do I change a standard perforce user to a super user? Seen lots of questions on what to do if the super user password is lost but none on how to create another super user, or give a current user super user permissions.
You will need to update the Perforce Protections table for that user.
For example:
write user jen * //...
becomes:
super user jen * //...
More information about Perforce Protections is here:
http://www.perforce.com/perforce/doc.current/manuals/p4sag/chapter.protections.html
Hope this helps,
Jen.
Related
Scenario 1
Imagine, you have several Admins, all they have their own ser name like tom, john, adam. They all are able to be root. This means that everyone could be root at the same time and issue sensitive commands. Is there a way to determine afterwards who has logged in as root AND who has used which command as root? For example, Tom logged in as root and rebooted the server, or John logged in as root and restarted Tomcat, etc.
Scenario 2
Similar to scenario 1, with the difference that the admins do not have a personal user name, but use a shared user and then log in as root. In this case, is it possible to check afterwards who logged on with the shared username and what he did afterwards as root? Is this logged in the system (IP or other data)
__
Can you recommend a simple, lean authorization concept for root users, with which you can see who did what on the servers? Access to the server should remain largely simple, e.g. via mRemote.
Here is what I think could somehow work for :
Senario 1
You can always watch the content of ~/.bash_history but the user can edit/remove the file.
Also if the user uses su and not sudo, you won't see anything
Senario 2
You can use the sshd logs to see who connected using what have been done here https://serverfault.com/questions/130482/how-to-check-sshd-log
Or in the ~/.bash_login file you can log the $SSH_CLIENT into something (sent it with curls, echo it into a log file), but here also keep in mind that user can edit ~/.bash_login
I have an existing SVN server and I need to add more users to connect using subversion clients to do checkout, updates and commits. I read documents (http://svnbook.red-bean.com/en/1.7/svn.serverconfig.svnserve.html#svn.serverconfig.svnserve.auth.users) on how to adding new users to the svn server but I couldn't get a good idea.
Please somebody just help me to find out the correct way to add new users and grants privileges.
my problem is I have a SVN server with user "aaa" with administrative privileges. I need to add an another user call "bbb" with same privileges.
Can svn commands use to create new user account after set-up the SVN Server ?
or do I need to manually edit existing .conf file to add new users for SVN server ?
Server OS is CentOS 6.3
As Rup explained in the comments. I found /etc/svn-auth-conf and list all existing users. Then added a new user using below
htpasswd -m /etc/svn-auth-conf <userName>
then new password, and password confirmation are prompted.
its worked.
I have a perforce path //depot/MAIN/submain/...
I want to deny write access to all users and groups so that no commits will happen for the above mentioned path in perforce.
I tried adding this in the protection table,
write group * * -//depot/MAIN/submain/...
write user * * -//depot/MAIN/submain/...
I have not tested this on prod environment, Please let me know if these are the correct permissions to accomplish my task.
Also please let me know how to deny write access to all users and groups except me for the branches associated to the above path,
//depot/branches/submain1.0
Regards and Thanks in advance.
Adding more queries on super privileges,
Hi,Thanks for the reply. I was able to apply restrictions as required. There is a small clarification needed on super privileges and how it works. Please look at the below example so that you can understand my thought better, I have a main folder //depot/main
I can use super group groupname * -//depot/main/... to deny all privileges to "groupname"
Now i want to provide write access to the same group "groupname" to a sub folder "//depot/main/project". Can i give write group groupname * //depot/main/project. Do the write privilege overwrite the already provided super privileges?
Please help me in this regard since i can t test privileges in prod and we don't have a clone to work on this.
Here is an example to deny all users except you to those branches you mentioned.
If your user name is 'admin' for example:
write user * * -//depot/MAIN/submain/...
write user * * -//depot/branches/submain1.0
super user admin * //...
Here are references:
Exclusionary Protections
http://answers.perforce.com/articles/KB_Article/Exclusionary-Protections
How Protections are implemented
http://www.perforce.com/perforce/doc.current/manuals/p4sag/chapter.protections.html#DB5-20008
for Example I will make a user called username
I need to grant all root privileges to user username
Think through this carefully, do this user really need access to everything root does? Because it is a security list. The approach I have taken is to only given the access needed to another user such as apache, for example for that is truly needed. I know it is easier to just give another user all access that root has but things can get sloppy pretty easily this way.
If you want to grant all root privileges, why not not use username root in the first place?
We are more than 1 user working on SQLyog (webyog), we all use root to login, recently it has been brought to my attention that some confidential data has been leaked from 1 of the tables that I work on. I have been instructed to have a look into this. Can I protect this table with a new user account from root?
Change the root password immediately.
Your employer is liable for a couple incidents given your scenario.
If confidential info of any kind is being stored on that server, only the people with proper training and classification should have access to said information.
You should create a new user for EACH employee (or for each employee type [e.g: 'root', 'accounting', 'library', 'developer']) and give permissions accordingly.
The only user with global access should be root, and possibly whatever developer account you may create.
Everyone else should have access only to the tables they need and only have access to basic CRUD (Create, Update, Delete) functions. Your accountant may know basic SELECTing statements, but he shouldn't be DROPping tables.