Re: Perforce Security
What you can do for authentication for the time being is to use just any ol' user that happens to have a valid account and set that in the Repository setting. There's no need for it to be some special account. In practice, any will work, and we used to use David's at VMware for a while. Don't set a password in there yet. We'll be putting a ticket value there instead. Then, according to the Perforce System Administrator's Guide, do a 'p4 login' as your user, then 'p4 login -p' to get the ticket value. You should be able to paste this value in as the password and it should accept it, meaning no passwords will need to be stored in the database. The downside to a ticket is that it expires by default, but the Perforce admin can set that user's ticket to not expire by putting that user in a group and then, in the group config, setting Timeout: to 0. Christian -- Christian Hammond - [EMAIL PROTECTED] VMware, Inc. On Sun, Sep 21, 2008 at 2:32 PM, Christian Hammond [EMAIL PROTECTED]wrote: I'd have to read up on how p4 tickets work, but it's still not that simple. Remember that the server needs a way to access the content, and then caches it so that future lookups are quick. This means that once one person provides the necessary information to access the file, it'll be available for all users until it drops out of the cache. To make this work, we'd need much finer-grained permission support with a repository backend. We'd need to be able to query on a per-file basis that a particular user has access to the server. This means several Perforce server calls on every page access, which will slow things down a little bit, especially for large diffs, and negate many of the speed and server-load benefits of our caching. We'd also need a good way of associating Perforce users with local users, which we don't have yet. Another option is to have the permissions control stay local to Review Board. Users would be unable to access anything not approved by the Review Board administrator. It would stay relatively fast without the complexity of having to link accounts (something which would take additional per-user configuration and introduce codebase changes I'm not too excited about), and would stay more general across other revision control systems. This is work we'd need someone to champion, and probably wouldn't start until after the 1.0 release unless someone gets it done fast. Christian -- Christian Hammond - [EMAIL PROTECTED] VMware, Inc. On Sun, Sep 21, 2008 at 12:43 PM, Daniel Wexler [EMAIL PROTECTED]wrote: Can we use p4 tickets somehow to solve this problem? Would it be possible for each user to log in once per session using a password that isn't saved anywhere, and retain permissions for that user with a ticket? Obviously we shouldn't store passwords in cleartext or with bad encryption. But I wouldn't mind entering a password once a day (or a couple times) manually to get things started. Would requiring the password on each session should also get us around the password change issue? I'm pretty sure my IT dept won't allow us to store a password for the respository in our config files. Our IT department will not provide a special account for the server. Even read-only access is not secure enough. We need to prevent employees without access from *reading* files within parts of the repository for which they don't personally have access. The danger for us is the release of the IP, not the ability to modify the code. For us, and I'm sure many others, solving this issue will be essential to our use of reviewboard. On Sep 19, 8:37 pm, Christian Hammond [EMAIL PROTECTED] wrote: This isn't a very usable solution, for a few reasons. First, we can't use the user's Review Board username/pass, because this won't always correspond to the account on the Perforce server. Also, passwords are one-way encrypted so that they can't easily be decrypted if the database is accessed by a malicious user. Given that, we'd have to specify the user/pass to use on every operation. Since Review Board pulls files from the Perforce server when generating a diff, which may happen at any time, we'd have to store the user/pass in plaintext in the database, which is horribly insecure. IT admins generally wouldn't be okay with this, and it would just be irresponsible for us to implement. We could do a sort of two-way encryption but this isn't really much better. Yes, we are storing the repository account's password in plaintext, but the general advice is to have a read-only user account or something so that if someone has the password, they can't do anything too dangerous. It's also far better than to have every single user's password available in plaintext. Also, if a user changes his username/password at a later time on the Perforce server, or the user is removed from the Perforce server, all associated review requests would
Re: Perforce Security
This is how I have mine setup. I use my account in reviewboard and every time my ticket expires I use p4 login -a -p. I have found that I need the -a to allow my ticket to work from any computer. Sent from my iPhone On Sep 21, 2008, at 5:54 PM, Christian Hammond [EMAIL PROTECTED] wrote: What you can do for authentication for the time being is to use just any ol' user that happens to have a valid account and set that in the Repository setting. There's no need for it to be some special account. In practice, any will work, and we used to use David's at VMware for a while. Don't set a password in there yet. We'll be putting a ticket value there instead. Then, according to the Perforce System Administrator's Guide, do a 'p4 login' as your user, then 'p4 login -p' to get the ticket value. You should be able to paste this value in as the password and it should accept it, meaning no passwords will need to be stored in the database. The downside to a ticket is that it expires by default, but the Perforce admin can set that user's ticket to not expire by putting that user in a group and then, in the group config, setting Timeout: to 0. Christian -- Christian Hammond - [EMAIL PROTECTED] VMware, Inc. On Sun, Sep 21, 2008 at 2:32 PM, Christian Hammond [EMAIL PROTECTED] wrote: I'd have to read up on how p4 tickets work, but it's still not that simple. Remember that the server needs a way to access the content, and then caches it so that future lookups are quick. This means that once one person provides the necessary information to access the file, it'll be available for all users until it drops out of the cache. To make this work, we'd need much finer-grained permission support with a repository backend. We'd need to be able to query on a per- file basis that a particular user has access to the server. This means several Perforce server calls on every page access, which will slow things down a little bit, especially for large diffs, and negate many of the speed and server-load benefits of our caching. We'd also need a good way of associating Perforce users with local users, which we don't have yet. Another option is to have the permissions control stay local to Review Board. Users would be unable to access anything not approved by the Review Board administrator. It would stay relatively fast without the complexity of having to link accounts (something which would take additional per-user configuration and introduce codebase changes I'm not too excited about), and would stay more general across other revision control systems. This is work we'd need someone to champion, and probably wouldn't start until after the 1.0 release unless someone gets it done fast. Christian -- Christian Hammond - [EMAIL PROTECTED] VMware, Inc. On Sun, Sep 21, 2008 at 12:43 PM, Daniel Wexler [EMAIL PROTECTED] wrote: Can we use p4 tickets somehow to solve this problem? Would it be possible for each user to log in once per session using a password that isn't saved anywhere, and retain permissions for that user with a ticket? Obviously we shouldn't store passwords in cleartext or with bad encryption. But I wouldn't mind entering a password once a day (or a couple times) manually to get things started. Would requiring the password on each session should also get us around the password change issue? I'm pretty sure my IT dept won't allow us to store a password for the respository in our config files. Our IT department will not provide a special account for the server. Even read-only access is not secure enough. We need to prevent employees without access from *reading* files within parts of the repository for which they don't personally have access. The danger for us is the release of the IP, not the ability to modify the code. For us, and I'm sure many others, solving this issue will be essential to our use of reviewboard. On Sep 19, 8:37 pm, Christian Hammond [EMAIL PROTECTED] wrote: This isn't a very usable solution, for a few reasons. First, we can't use the user's Review Board username/pass, because this won't always correspond to the account on the Perforce server. Also, passwords are one-way encrypted so that they can't easily be decrypted if the database is accessed by a malicious user. Given that, we'd have to specify the user/pass to use on every operation. Since Review Board pulls files from the Perforce server when generating a diff, which may happen at any time, we'd have to store the user/ pass in plaintext in the database, which is horribly insecure. IT admins generally wouldn't be okay with this, and it would just be irresponsible for us to implement. We could do a sort of two-way encryption but this isn't really much better. Yes, we are storing the repository account's password in plaintext, but the
Re: Perforce Security
So, I think we already are using the official Perforce Python module. That's good (it makes my IT guys happy). Why do we use the client and repository setting for the Repository instead of using a client/pass from the user? I think my IT guys would be happy if we used the user's client/pass information when the server accesses the repository instead of a single, global user/pass. Just poking around the code, how would I get the reviewboard user/pass inside scmtools/perforce.py:19? If I had folks set up their reviewboard account using their same user/pass as they have with Perforce, would it all Just Work (tm)? On Sep 19, 5:00 pm, Daniel Wexler [EMAIL PROTECTED] wrote: Has anyone explored the new Python bindings for Perforce? http://www.perforce.com/perforce/doc.081/manuals/p4script/p4script.pdf They seem to have functions for logging in to the server with a specific user name and password from Python. Could we use this and have the user's provide the Perforce user/pass as part of their client info? On Sep 19, 4:43 pm, Jeff Andros [EMAIL PROTECTED] wrote: it's not a pretty solution, but what about setting up multiple reviewboard instances, with different user credentials in each (one for each project you've got) then you only create accounts on the servers that theyr'e supposed to have access to. Jeff O|||O Help me and the Leukemia and Lymphoma society fight blood cancers:http://pages.teamintraining.org/dm/tucson08/jandros On Fri, Sep 19, 2008 at 4:30 PM, Daniel Wexler [EMAIL PROTECTED] wrote: I see an older discussion about the issue of Perforce security and the need to put the P4 user and client information into the server: http://groups.google.com/group/reviewboard/browse_thread/thread/d057c... Any update on this situation? My company is similarly concerned about this security issue and would like a way of passing through the user's perforce credentials. Is anyone actively working on this issue? We have a large company and have many internal security groups. There have been issues in the past with server accounts that make the IT department hesitant to set up a special Perforce account for the server. Can someone explain why the server needs Perforce access in the first place? Why not just upload the required information as part of the user-side post-review script? BTW, I did install Windows NTLM authentication on my server using mod_auth_sspi with no issues so far, which provides a modicum of security. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups reviewboard group. To post to this group, send email to reviewboard@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/reviewboard?hl=en -~--~~~~--~~--~--~---
