Thanks for the info David. I understand how Perforce handles
permissions, but I didn't make myself clear. Your point #2
answers my question.
The problem was that someone in the Build/Release group has
full access to the Perforce server repository. My consulting
assignment here is ending soon so I am transitioning the Perforce
admin work to this person. Even though I have told her twice
already, she thinks that the Perforce depot (/opt/perforce/repository)
on the server operates the same as the previous CVS repository. She
tries to map her client view to match the depot directory structure.
She thought she had a permission problem because the permission on
the server directory was dr-xr-xr-x. It was actually a problem with
her client view.
Thanks,
Jack Stanley
IT Consultant
Covad Communications
-----Original Message-----
From: David Jones [mailto:drj@xxxxxxxxxxxxxx]
Sent: Thursday, January 29, 2004 2:38 AM
To: Stanley, Jack
Cc: <perforce-user@xxxxxxxxxxxx>
Subject: Re: [p4] Directory permissions in the depot
On Jan 28, 2004, at 22:28, Stanley, Jack wrote:
>
> I'm wondering how permissions on files in the depot affect your
> ability to do syncs. For instance if you have the following:
>
> dr-xr-xr-x DIRECTORY
> -r--r--r-- DIRECTORY/FILE
>
> versus:
>
> drwxrwxrwx DIRECTORY
> -r--r--r-- DIRECTORY/FILE
>
> will any user still be able to do unrestricted syncs in each case?
Your question indicates a small amount of confusion. Perhaps I can
dispell it.
When you say "permissions of files" there are several things you could
mean:
1) The UNIX file mode on the file when it is on a user's disk having
been placed there by 'p4 sync or similar.
2) The UNIX file mode on the files managed by the perforce server in
the repository on the server's disk. This is irrelevant and you
certainly shouldn't be messing around there.
3) Perforce permissions. Perforce stores a database of who can do what
to which files. This is the way to stop being being able to sync /
submit.
Directories are not stored in perforce. The area on the server's disk
that the perforce server uses to manage the repository might have
directories in it but from a user's viewpoint they are irrelevant, and
as per 2) above you certainly shouldn't be messing around there.
If a user has a directory on their disk that they do not have write
permission on then they will not be able to do any syncs involving that
directory. Ordinarily this won't happen because when perforce creates
directories, which it does as part of p4 sync, it will create them so
that they are writable by the user (you can break this by changing your
umask).
When a user does a submit perforce only looks at the files, not the
directories.
The file mode of a file is examined by perforce and is managed by
perforce. When a file is sync'ed perforce will make it read-only on
the client's disk; when a file is opened for edit perforce will make it
writable on the client's disk; when a file is submitted perforce will
make the copy on the client's disk read-only. This can be changed with
allwrite option on the client (for all files on that client), and also
(on a per-file basis) with the +w filetype (see p4 help filetypes).
The x bit of the file mode can be changed with the +x filetype, though
perforce will generally get it right at the time that the file is
added.
If you want to prevent people from doing certain things, for example
prevent them from being able to sync the //depot/accounts/... hierarchy
then it is 3) in the above list that you need to investigate, Perforce
Permissions. Basically you can create groups of users and have only
specific groups be able to do certain things to various parts of the
file hierarchy. Chapter 4 of the SAG explains it in detail,
http://www.perforce.com/perforce/doc.032/manuals/p4sag/04_protect.html
I hope that helps.
David Jones
Ravenbrook Limited
_______________________________________________
perforce-user mailing list - perforce-user@xxxxxxxxxxxx
http://maillist.perforce.com/mailman/listinfo/perforce-user
|
