3 messages in com.perforce.perforce-user[p4] Perforce files security| From | Sent On | Attachments |
|---|---|---|
| Yariv Sheizaf | 23 Jul 2000 03:45 | |
| Jeff A. Bowles | 23 Jul 2000 08:14 | |
| Meyer, Maurice | 24 Jul 2000 09:41 |
| Subject: | [p4] Perforce files security |
|---|---|
| From: | Meyer, Maurice (Maur...@nonstop.com) |
| Date: | 07/24/2000 09:41:19 AM |
| List: | com.perforce.perforce-user |
Yariv,
For normal Perforce operations, users do not need to see the *,v files. So, don't share them or put them on a machine that people can login to. Or, if people do need to login to that machine, don't give read permissions on the files to anyone but the superuser running p4d.
Maurice
-----Original Message----- From: Yariv Sheizaf [mailto:yarivs at cimatron.co.il] Sent: Sunday, July 23, 2000 3:45 AM To: 'perforce-user at perforce.com' Subject: [p4] Perforce files security
Hi,
Perforce uses "p4 protect" method for permission policy.
I have some files which should be unseen to all users except the configuration manager (who is the superuser).
The problem is that the *,v files are not protcted as flat files. I mean - the Perforce user can not see them ( read user * * -//<unseen files>), but everybody can access them using explorer/DOS/Unix command line.
How can I protect these files ?
Yariv Sheizaf Software Infrastructure Department Manager Cimatron Ltd.
_______________________________________________ perforce-user mailing list - perforce-user at perforce.com http://maillist.perforce.com/mailman/listinfo/perforce-user
Received: from beamail.beasys.com (unknown-130-3.beasys.com [209.97.130.3])
by frankenrouter.perforce.com (8.9.3/8.9.1) with ESMTP id MAA09805
for <perforce-user at perforce.com>; Fri, 21 Jul 2000 12:22:04 -0700 (PDT)
Received: from san-francisco.beasys.com (san-francisco.beasys.com
[192.168.9.10])
by beamail.beasys.com (8.9.1b+Sun/8.9.1) with ESMTP id MAA13225
for <perforce-user at perforce.com>; Fri, 21 Jul 2000 12:21:42 -0700 (PDT)
Received: from ashbury.weblogic.com (ashbury.beasys.com [172.17.8.3])
by san-francisco.beasys.com (8.9.1b+Sun/8.9.1) with ESMTP id MAA12622
for <perforce-user at perforce.com>; Fri, 21 Jul 2000 12:21:34 -0700 (PDT)
Received: from heron.beasys.com ([172.17.10.65]) by ashbury.weblogic.com
(Post.Office MTA v3.5.3 release 223 ID# 0-53833U200L200S0V35)
with ESMTP id com for <perforce-user at perforce.com>;
Fri, 21 Jul 2000 12:38:37 -0700
Message-Id: <4.3.2.7.2.20000721121323.00d1a380 at ashbury.beasys.com>
X-Sender: chuck.karish at ashbury.beasys.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 21 Jul 2000 12:18:13 -0700
To: "'perforce-user at perforce.com'" <perforce-user at perforce.com>
From: chuc...@bea.com (Chuck Karish)
Subject: Re: [P4] Using P4 to help control build breakage
In-Reply-To: <EF45EA07AEA2D2118E920008C7B14102EA58A3 at mvex02.intuit.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: perforce-user-admin at perforce.com
Errors-To: perforce-user-admin at perforce.com
X-BeenThere: perforce-user at perforce.com
X-Mailman-Version: 2.0beta2
Precedence: bulk
List-Id: Discuss Perforce with other users <perforce-user.perforce.com>
At 10:14 AM 7/21/00, Africa, William wrote:
The current process for SCM builds consists of daily overnight build. There can be a multitude of changesets from one build to the next. And, it is the developer's responsibility to verify that his/her checkin will not break any other component in the build. The process is to sync to the tip and rebuild with your changes. Although it is easy and fast to verify your changeset will not break the build within your local component, it is another story whether it will not cause problems in other areas. The problem is that a complete rebuild takes over 2 hours. Thus, developer is suppose to either sacrifice 2 hours every time to verify his/her checkin or let the SCM overnight build catch any errors. In addition, other developers may be checking onto the tip while someone else is rebuilding (for 2 hours) what was the tip at the time he/she kicked off their rebuild. Neither development nor SCM can be guaranteed a reliable set of source at any point in time with the exception of the labeled overnight build. As a result, there is a high frequency of build breakage and low confidence in syncing to the tip. Also, SCM frequently delivers late to releases to QA thus delaying their time to begin testing.
Has anyone had a similar problem? If so, how was it resolved? Did anyone try a code promotion model to solve this? I've heard source control systems like ClearCase can track build dependencies and supply users with derived files (such as OBJs, PDBs, EXEs, etc.) when a user wants to sync to a verified set of source. Has anyone explored getting a similar implementation in Perforce?
We use a build daemon that syncs and builds whenever it detects that changes have been checked in. It maintains a last_clean_build label that gives users and the nightly test programs a safe haven in case someone breaks the build. Users are still expected to do their own builds to validate changes; the daemon is meant to provide a second check.
Chuck Karish BEA Systems (415) 402-7692 http://www.bea.com/