[p4] Tips to set up user accounts.

[Kalapatapu, Pallavi]

Hi,

I have been using the evaluation copy of perforce software for 10
licenses. I have been the user so far. now I want to create
9 other users and their client specs. Also, I want to place
myself as the super user and give the rest of the users
permissions enough to to be able to do all the normal
perforce operations that a normal software developer would
need to maintain his code. However, since I get to be the
admin in our group, I want to make sure that Perforce
depot is protected from unauthorized deletions on the depot.
What is the best approach for this?

What are the typical permissions that a perforce user would be given?
How can I enforce password protect for each one of them?

What is the best way to set up new user accounts? Via GUI or
command line?



I know that the first person who runs a perforce protect
becomes the super user. I think I did that some time back.


Any tips to set up user accounts?. What would be the other
necessary packages that a user would need other than
p4win(GUI), p4 command line client, p4winMrg?


thanks
pallavi

[Chuck Karish]

Post by Kalapatapu, Pallavi
Hi,
I have been using the evaluation copy of perforce software for 10
licenses. I have been the user so far. now I want to create
9 other users and their client specs. Also, I want to place
myself as the super user and give the rest of the users
permissions enough to to be able to do all the normal
perforce operations that a normal software developer would
need to maintain his code. However, since I get to be the
admin in our group, I want to make sure that Perforce
depot is protected from unauthorized deletions on the depot.
What is the best approach for this?

Create a group and make all ordinary users members of that group.

Post by Kalapatapu, Pallavi
What are the typical permissions that a perforce user would be given?

"open" access for files meant to be read-only.
"write" access for files meant to be changed by the users.

Allow access only through group membership. If there are any lines in
your permissions table (`p4 protect -o`) that give access to any individual
user with wildcards, users will have write access to the metadata to
create new users.

Post by Kalapatapu, Pallavi
How can I enforce password protect for each one of them?

You can't. That's a management issue.

Post by Kalapatapu, Pallavi
What is the best way to set up new user accounts? Via GUI or
command line?

Whatever seems easiest to you. I do it from the command line.

--
Chuck Karish ***@well.com [phone]

[Stephen Vance]

Post by Kalapatapu, Pallavi
Hi,
I have been using the evaluation copy of perforce software for 10
licenses. I have been the user so far. now I want to create
9 other users and their client specs. Also, I want to place
myself as the super user and give the rest of the users
permissions enough to to be able to do all the normal
perforce operations that a normal software developer would
need to maintain his code. However, since I get to be the
admin in our group, I want to make sure that Perforce
depot is protected from unauthorized deletions on the depot.
What is the best approach for this?

A simple approach is to set up two groups, P4Admin and dev, for
example. For the admin group, I deliberately chose something that is *not*
either 'root' or 'Administrator' so that people logged in as one of these
on either Unix or Windows don't accidentally become these Perforce users.

Define your groups ('p4 group P4Admin') such that the administration group
contains you and your peers, and the dev group contains all the developers.

Post by Kalapatapu, Pallavi
What are the typical permissions that a perforce user would be given?
How can I enforce password protect for each one of them?

Consider something like:

super group P4Admin * //...
write group dev //depot/...

depending on how you structure your depot and whether you have different
categories of users.

Post by Kalapatapu, Pallavi
What is the best way to set up new user accounts? Via GUI or
command line?

I prefer the command line with a good shell, like bash. Or you can
automate it through some shell scripting. The GUI won't let you manipulate
the groups tables.

Post by Kalapatapu, Pallavi
I know that the first person who runs a perforce protect
becomes the super user. I think I did that some time back.

Any super user can modify this, as well.

Post by Kalapatapu, Pallavi
Any tips to set up user accounts?. What would be the other
necessary packages that a user would need other than
p4win(GUI), p4 command line client, p4winMrg?

Use the command line with scripted commands. Use the -i and -o options to
create and suck in templates.

Post by Kalapatapu, Pallavi
thanks
pallavi

No problem. Good luck.

Steve


Stephen Vance
mailto:***@vance.com
http://www.vance.com/

[T***@sybase.com]

Post by Stephen Vance
A simple approach is to set up two groups, P4Admin and dev, for
example. For the admin group, I deliberately chose something that is

*not*

Post by Stephen Vance
either 'root' or 'Administrator' so that people logged in as one of these
on either Unix or Windows don't accidentally become these Perforce users.

Steve,

What are the advantages of having two groups? I would think
that
having groups would start paying off when three or more are required to
achieve additional granularity. For instance, we have several dozen users
all of whom
have read access to everything in every depot and each of whom has write
access to the depots of his or her application(s.) Then, we have the
'p4admin'
user and a handful of superusers with admin privileges. Why would we want
to implement Perforce groups? What am I missing?

Cheers,

Thom Wielski
Sybase Inc

[Kalapatapu, Pallavi]

Post by Stephen Vance
A simple approach is to set up two groups, P4Admin and dev, for
example. For the admin group, I deliberately chose something that is

*not*

Post by Stephen Vance
either 'root' or 'Administrator' so that people logged in as one of these
on either Unix or Windows don't accidentally become these Perforce users.

Steve,

What are the advantages of having two groups? I would think
that
having groups would start paying off when three or more are required to
achieve additional granularity. For instance, we have several dozen users
all of whom
have read access to everything in every depot and each of whom has write
access to the depots of his or her application(s.)


did you mean read access to all the directories under the depot and
a write access to only the concerned directories? Iam just trying
to clarify.( I guess you were not talking about multiple
depots. AS,in such case, users can have write access to
only one depot and read access to multiple remote depots)-----Thanks pallavi


Then, we have the
'p4admin'
user and a handful of superusers with admin privileges. Why would we want
to implement Perforce groups? What am I missing?

Cheers,

Thom Wielski
Sybase Inc

[Chuck Karish]

Why would we want to implement Perforce groups? What am I missing?

If you assign permissions to users, anyone who has access to your network
can create a new user. Either intentionally or accidentally; every reference
to a non-existent user will create a new one.

--
Chuck Karish ***@well.com [phone]

[Stephen Vance]

Sorry the response didn't get out sooner. My cable connection went down.

Post by T***@sybase.com

Post by Stephen Vance
A simple approach is to set up two groups, P4Admin and dev, for
example. For the admin group, I deliberately chose something that is

*not*

Post by Stephen Vance
either 'root' or 'Administrator' so that people logged in as one of these
on either Unix or Windows don't accidentally become these Perforce users.

Steve,
What are the advantages of having two groups? I would think
that
having groups would start paying off when three or more are required to
achieve additional granularity. For instance, we have several dozen users
all of whom
have read access to everything in every depot and each of whom has write
access to the depots of his or her application(s.)

"Two groups" is an oversimplification that meets a common case. I really
mean to set up as many groups as there are subcategories of users.

To meet the posed example, I would probably put everyone into an "allread"
group and then create project groups for the write permissions. The major
alternatives would be to have two or more lines for each group, one write
and the rest read, or to use a wildcard that overstates the intent should
the environment change significantly.

In general, creating groups to express your meaning lays the foundations
for growth and adds a self-documenting aspect to your protection table
through the group names.

Another group I have created in the past is "Unallocated" which contains
token users to fill the gap between the actual number of users and the
number of licenses. This prevents accidental additions of users through
connections from a poorly configured environment or worse. Another
approach to this is to explicitly exclude permission to anyone not
explicitly named below with

write user * -//...

as the first line of the protections.

Post by T***@sybase.com
did you mean read access to all the directories under the depot and
a write access to only the concerned directories? Iam just trying
to clarify.( I guess you were not talking about multiple
depots. AS,in such case, users can have write access to
only one depot and read access to multiple remote depots)-----Thanks pallavi

The scenario I proposed allows write access to all developers in the
default depot, assuming you have only one depot active. The entry allowing
access in all depots to the admins allows any of the admins to create new
depots. Otherwise, you would not be able to create new depots without
updating the protections.

Post by T***@sybase.com
Then, we have the
'p4admin'
user and a handful of superusers with admin privileges. Why would we want
to implement Perforce groups? What am I missing?

Perhaps you want multiple admins. Perhaps you trust one or more of your
users to run as admin all the time. Perhaps you want to define multiple
levels or domains of administration with some common privileges.

Essentially the reason to use groups is to prepare for future growth, to
make the protection table somewhat self-documenting, and possibly to
protect your excess licenses.

Steve


Stephen Vance
mailto:***@vance.com
http://www.vance.com/

[Schaible, Jorg]

Hi,

while the answers of Steve are very valuable in this thread, please

Post by Stephen Vance

Post by Kalapatapu, Pallavi
What are the typical permissions that a perforce user would be given?
How can I enforce password protect for each one of them?

super group P4Admin * //...
write group dev //depot/...

Please have the super line always be the last line in the protections. If
you are the only member of the P4Admin group and you become also member of
the dev group, BINGO! You won't have any administrations rights anymore and
no-one can grant them again. Remeber: The access rights follow the normal
mechanism of hierarchy like the mappings in the client specs.

So to prevent Perforce creating accounts for new users and follow the advice
of Steve you should end-up with protecions like:

list user * * -//...
write group dev //depot/...
super group P4Admin * //...

Greetings,
Jorg


BTW: The only possible solution to recover from such an situation is to kill
the P4 server, remove the line setting the wrong member ship (or protection)
in the journal and recover from the last checkpoint and this modified
journal. Well, this implies that you have a checkpoint and activated the
journal <g> ...

[Schaible, Jörg]

Hi Robert,

I think the behaviour listed by Jorg is a bug, or at least it
goes against
the documentation in
http://www.perforce.com/perforce/doc.002/manuals/p4sag/04_protect.html#1045

243

protect a
super
a This command doesn't operate on specific files. Thus, permission is
granted to run the command if the user has the specified
access to at least
one file in the depot.
I have tested it as shown by my journal (and indeed could no
longer run p4

[snip]
Can you show also your protections for both cases? I guess it depends on the
access for "at least one file". Have a look:

super group P4Admin * //...
write group dev //depot/...

If there is any file in a second depot, you should have access to p4 protect
despite your membership in both groups.

Each line contains a protection mode, a group/user
indicator, the
group/user name, client host id and a depot file path pattern.
A user gets the highest privilege granted on any line.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

If the manual is right, the online help should be updated to this "at least
one file access" behavior.

Greetings,
Jörg



Here's the original, since it was not cc'd to the list ...

-----Original Message-----
Sent: Wednesday, June 20, 2001 11:10 AM
Cc: Schaible, Jörg
Subject: FW: [p4] Tips to set up user accounts.
I think the behaviour listed by Jorg is a bug, or at least it
goes against
the documentation in
http://www.perforce.com/perforce/doc.002/manuals/p4sag/04_prote
ct.html#10452
43
protect a
super
a This command doesn't operate on specific files. Thus, permission is
granted to run the command if the user has the specified
access to at least
one file in the depot.
I have tested it as shown by my journal (and indeed could no
longer run p4
C:\Perforce>tail journal
@pv@ 2 @db.group@ @robert@ @p4admin@ 0 0
@pv@ 2 @db.group@ @bruno@ @dev@ 0 0
@pv@ 2 @db.group@ @robert@ @dev@ 0 0
@pv@ 2 @db.protect@ 0 0 @p4admin@ @*@ 127 0 @//...@
@pv@ 2 @db.protect@ 1 1 @dev@ @*@ 31 0 @//...@
C:\Perforce>
My understanding was that you would get the highest permission
granted by
any protect lines, as long as the first one encountered
(reading bottom to
top) is not an exclusionary line.
Each line contains a protection mode, a group/user
indicator, the
group/user name, client host id and a depot file path pattern.
A user gets the highest privilege granted on any line.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@rv@ 2 @db.user@ @robert@ @robert@@bruno_ws@ @@ 991907861
@@
@rv@ 2 @db.user@ @robert@ @robert@@bruno_ws@ @@ 991907861
@@
@rv@ 2 @db.user@ @robert@ @robert@@bruno_ws@ @@ 991907861
@@
@pv@ 2 @db.protect@ 0 0 @robert@ @*@ 127 0 @//...@
@pv@ 2 @db.protect@ 1 0 @robert@ @*@ 31 0 @//...@
@pv@ 2 @db.protect@ 2 0 @bruno@ @*@ 31 0 @//...@
@pv@ 2 @db.protect@ 3 0 @carrie@ @*@ 127 0 @//...@
@pv@ 2 @db.group@ @carrie@ @p4admin@ 0 0
@pv@ 2 @db.group@ @robert@ @p4admin@ 0 0
@rv@ 2 @db.protect@ 0 1 @p4admin@ @*@ 127 0 @//...@
@rv@ 2 @db.protect@ 1 0 @robert@ @*@ 31 0 @//...@
@rv@ 2 @db.protect@ 2 0 @bruno@ @*@ 31 0 @//...@
@rv@ 2 @db.protect@ 3 0 @carrie@ @*@ 127 0 @//...@
@dv@ 2 @db.protect@ 3 0 @@ @@ 0 0 @@
@pv@ 2 @db.group@ @bruno@ @dev@ 0 0
@pv@ 2 @db.group@ @robert@ @dev@ 0 0
@rv@ 2 @db.protect@ 1 1 @dev@ @*@ 31 0 @//...@
@dv@ 2 @db.protect@ 2 0 @@ @@ 0 0 @@
@dv@ 2 @db.group@ @carrie@ @p4admin@ 0 0
@rv@ 2 @db.user@ @robert@ @robert@@bruno_ws@ @@ 991907861
@@
@rv@ 2 @db.user@ @bruno@ @bruno@@bruno@ @@ 884221002 993028003
@bruno@ @@
@rv@ 2 @db.protect@ 0 0 @bruno@ @*@ 127 0 @//...@
@rv@ 2 @db.protect@ 1 1 @dev@ @*@ 31 0 @//...@
@rv@ 2 @db.protect@ 0 1 @p4admin@ @*@ 127 0 @//...@
@rv@ 2 @db.protect@ 1 1 @dev@ @*@ 31 0 @//...@
(All is OK - I can run p4 protect as robert)
There seems to be something strange going on.....!!
Robert
p.s. Server version: P4D/NTX86/2000.2/19520 (2000/12/18)

-----Original Message-----
Sent: Wednesday, June 20, 2001 08:42
Subject: RE: [p4] Tips to set up user accounts.
Hi,
while the answers of Steve are very valuable in this thread, please
recognize that his advice for the protection lines are

Post by Stephen Vance

Post by Kalapatapu, Pallavi
What are the typical permissions that a perforce user

would be given?

Post by Stephen Vance

Post by Kalapatapu, Pallavi
How can I enforce password protect for each one of them?

super group P4Admin * //...
write group dev //depot/...

Please have the super line always be the last line in the

protections. If

you are the only member of the P4Admin group and you become

also member of

the dev group, BINGO! You won't have any administrations rights
anymore and
no-one can grant them again. Remeber: The access rights

follow the normal

mechanism of hierarchy like the mappings in the client specs.
So to prevent Perforce creating accounts for new users and follow
the advice
list user * * -//...
write group dev //depot/...
super group P4Admin * //...
Greetings,
Jorg
BTW: The only possible solution to recover from such an situation
is to kill
the P4 server, remove the line setting the wrong member ship (or
protection)
in the journal and recover from the last checkpoint and this modified
journal. Well, this implies that you have a checkpoint and

activated the

journal <g> ...

[Schaible, Jörg]

Hi,

Paul has given another very valuable solution for this access right deadlock

Sent: Wednesday, June 20, 2001 10:48 AM
To: Schaible, Jörg
Subject: RE: [p4] Tips to set up user accounts.

[snip]

FYI - it's not the only way. (But the other way
certainly isn't for beginners!)
1. Take a checkpoint (anyone can do this).
2. "grep" for the "db.protect" records.
3. Find all records that are restricting your
"super" access rights.
4. Working on a copy of those records, substitute
Save that copy (to a file)
(p4d -jr "filename").
You DO NOT have to stop the server to do this.
6. You can now run "p4 protect".
Like I said, not for beginners...
Paul.

Thanks. Paul, this was really interesting. While I have really some
experience in modifying checkpoints and journals, I never recognized the
@dv@ lines. Just curious, what does it mean exaclty?

Greetings,
Jörg


BTW: Has anyone ever tried the Berkley DB support of MySQL to access the
db.* files of Perforce? It is just an idea, but I had never the time ...

[Stephen Vance]

Post by Schaible, Jorg
Hi,
while the answers of Steve are very valuable in this thread, please

Under certain conditions, this is true.

Post by Schaible, Jorg

Post by Stephen Vance

Post by Kalapatapu, Pallavi
What are the typical permissions that a perforce user would be given?
How can I enforce password protect for each one of them?

super group P4Admin * //...
write group dev //depot/...

Please have the super line always be the last line in the protections. If
you are the only member of the P4Admin group and you become also member of
the dev group, BINGO! You won't have any administrations rights anymore and
no-one can grant them again. Remeber: The access rights follow the normal
mechanism of hierarchy like the mappings in the client specs.

In the absence of exclusionary mappings, permissions are additive and the
highest permission applies *regardless of order*.

In the presence of exclusionary mappings, the order is significant, and it
is wise to put the super entry last in case a super user is excluded in a
previous rule.

Apologies for recommending a potentially difficult configuration.

Post by Schaible, Jorg
So to prevent Perforce creating accounts for new users and follow the advice
list user * * -//...
write group dev //depot/...
super group P4Admin * //...
Greetings,
Jorg

Although the successive discussion highlights a probable bug, I have never
encountered that particular problem and have only encountered behavior
consistent with the documentation.

Steve


Stephen Vance
mailto:***@vance.com
http://www.vance.com/

[Schaible, Jorg]

Hi Steve,

Post by Stephen Vance
In the absence of exclusionary mappings, permissions are
additive and the
highest permission applies *regardless of order*.
In the presence of exclusionary mappings, the order is
significant, and it
is wise to put the super entry last in case a super user is
excluded in a
previous rule.

you're right, I found this in the manual, too. I was not aware of that P4
has two different "modes" interpreting the access rights. IMHO at least a
hint should also be written in the "p4 help protect" and the man page. I was
once bitten by "excluding all administrators" accidently.

Greetings,
Jorg

BTW: Yes, I recognized, that there are no "two modes" and I am aware of that
the algorithm behaves additive and order has no meaning with the absence of
exclusions.