[p4] Trying to sort out a protection issue - never mind...

Ivey, William william_ivey at bmc.com
Tue Sep 26 08:37:36 PDT 2006


Good suggestions all, but I took the simpler route of giving
the machine its own scheduled task (I was trying to add it to
the main server's backup scripts) and just running "p4d -z -jc"
which bypasses the whole Perforce permission thing.

I really didn't want to give this ID super access anywhere, in
any case.

-Wm


> -----Original Message-----
> From: Weintraub, David [mailto:david.weintraub at bofasecurities.com]
> Sent: Tuesday, September 26, 2006 7:50 AM
> To: Ivey, William; perforce-user at perforce.com
> Subject: RE: [p4] Trying to sort out a protection issue - 
> never mind...
> 
> 
> As you discovered, checkpoints can only be run by the superuser.
> 
> So, the user that must run the checkpoint must be a super 
> user. However,
> this is a super user for Perforce and not root. This means 
> that you can
> limit that particular user's access quite a bit without too many
> problems.
> 
> You need to do the following:
> 
> * Create a system user on that machine and only that machine. For
> example, if you have a Unix system, this would be a user in the
> /etc/passwd table and not in the NIS table.
> 
> * Create a Perforce super user for that particular system 
> user in order
> to do the checkpoint. You could use the same super user as 
> your Perforce
> administrator, but because of the next step, you probably 
> want a second
> super user.
> 
> * Create a group for this user, and this user only. Set the 
> timeout for
> this group to zero. That way, if someone else falls into this 
> group, it
> won't affect their Perforce login ticket timeout length.
> 
> * On the machine in question, log in as the system user. 
> Then, log in as
> the Perforce super user. Make sure that you are using Perforce ticket
> authentication. By default, this will create a ticket file under the
> user's HOME directory (on Unix called .p4ticket). Make sure 
> this system
> user is the only one with read/write permission on this 
> ticket file. (It
> will be this way by default on Unix. On Windows, I sometimes find that
> other "admin" groups may have read/write rights.)
> 
> * If you're on a Unix system, create a cronjob for this user 
> to run the
> checkpoint. Use the Perforce ticket for this user as the 
> password (p4 -u
> <userId> -p <ticketfile> ...). If you're on Windows, create a schedule
> task for this user.
> 
> * On Unix systems, you can change the password for this system user in
> the password database to either "*" or "*LK*". This will 
> prevent anyone
> from logging in as that user. However, cron jobs will still run as
> scheduled. I don't think there is a Windows equivalent way of doing
> this.
> 
> In the end, you've created a cron job that is run by the system user
> that uses the Perforce superuser account to do the 
> checkpoint. However,
> that system user has a live forever ticket, so none of your scripts
> contain the actual password for this user. Instead, it uses a ticket
> file that is unreadable by anyone except this specific system user. On
> Unix systems, you've also prevented anyone (except the root 
> user) to be
> able to login as this user in order to user that system 
> user's Perforce
> ticket.
> 
> I take it that you're going through all of this as a way of backing up
> your Perforce server. You have another system that is running the
> backups, and you want to do the checkpoint before you backup the
> Perforce depot.
> 
> -----Original Message-----
> From: perforce-user-bounces at perforce.com
> [mailto:perforce-user-bounces at perforce.com] On Behalf Of Ivey, William
> Sent: Monday, September 25, 2006 2:59 PM
> To: perforce-user at perforce.com
> Subject: Re: [p4] Trying to sort out a protection issue - 
> never mind...
> 
> 
> Just realized I needed super access, not admin. I thought my current
> scripts were running p4 admin to do checkpoints, but they are running
> p4d directly. (I was looking at an old
> script.)
> 
> Kind of a bummer since I really don't want to grant this ID 
> super access
> even on a single machine.
> 
> -Wm
> 
> _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user
> 
> 



More information about the perforce-user mailing list