RE: Administrivia -- RE: Per-modules readers/writers ?
::I have just read that Mailman can be used to produce a ::Majordomo type roster of users, by email request (necessary, ::as I do not have shell access to the Mailman host) -- If I can ::get that roster (a couple thousand names), I will issue a ::serialized vacation tracer to each user, and weed some stale ::accounts out. :: How do you get that roster? Regards, Shabbir. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Per-modules readers/writers ?
Todd Denniston writes: This is the point where you set down, add up what it will cost your company to support your number of users by putting addons on a ''cheapskates'' version control system to support its use in the companies IP policy setup. Oh, please.. Well, is it the consensus of the maintainers that they will *never* accept any access control feature patches for CVS? Or is it that if someone is willing to back-port and contribute this from the CVSNT side, they will accept it? I.e. is the opposition to ACLs a matter of priorities, or philosophy? If it is philosophy, is it the position of the maintainers that ACLs are so evil that they will actively oppose any attempt by anyone to insert such a feature into CVS, in order to protect innocent users from this heresy? Just asking all these idiotic questions because no one is addressing that point. All I'm seeing are comments along the lines of if your company VPs cannot all take time to sit down and do a top-down reorganization of your IT department to take advantage of CVS as it stands in its purity today, just go away and don't bother us. Oh, heck, never mind - stupid me for offering to investigate this. Let's kill this topic and get back to the regular topics of discussion.. -- Shankar. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Per-modules readers/writers ?
Larry Jones wrote: A bit of both, I suspect. That's good to know. In any case, I'll take a closer look at the CVSNT stuff (I wish they hadn't gone and reformatted all their sources so much :-/), and see what's portable back to the main line.. Some basic features (cvs passwd, cvs ls, etc.) should be easy to backport. Others (ACLs, all the NT-specific stuff, etc.) may be a lot more messy, and probably won't be solid enough to pass muster anyway (so this long argument may be moot, for all you know..) -- Shankar. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Per-modules readers/writers ?
[ On Tuesday, October 29, 2002 at 09:10:44 (-0800), Shankar Unni wrote: ] Subject: RE: Per-modules readers/writers ? Well, is it the consensus of the maintainers that they will *never* accept any access control feature patches for CVS? Nobody can arrive at any consensus on this kind of thing without first seeing a complete design and functional specification for the proposed features. You haven't proposed anything concrete enough yet to even dream of whether it should be included in what we call CVS today. I.e. is the opposition to ACLs a matter of priorities, or philosophy? If it is philosophy, is it the position of the maintainers that ACLs are so evil that they will actively oppose any attempt by anyone to insert such a feature into CVS, in order to protect innocent users from this heresy? You still don't seem to understand that it's a fundamental design issue that hinges off the choice to use RCS for the underlying repository You cannot securely implement access controls to internal structural elements in CVS/RCS. It is simply not possible. There's no way to expose those internal structures to the OS in such a way that it can provide the necessary authorisation controls. If you're going to implement security features then you'd damn well better make sure they're for real because if you add some hack that gives a false sense of security and then some other bumbling fool uses it without knowing that it really doesn't provide any true security, then you would be directly responsible (in the moral sense, and perhaps even in the legal sense in some jurisdictions) for any damage done. Philosophically I doubt anyone has any conflict with the _idea_ of having finer-grained access controls for things like branches and tags and commit logs and whatnot. However if you want to design and implement something like that then you're going to have to toss out the whole underlying RCS layer, and if you're going to do that then you may as well just toss out the whole thing and start from scratch (well maybe retain the command-line interface and perhaps the client/server protocol for compatability's sake). Even the suggestion of using a closed host system and perverting all the security into the network server application isn't going to provide any real security if it's based on anything even remotely related to the current CVS code base. Even if you cleaned up the current code base so that it could be better trusted as a security application; and re-engineered some of the internal administrative control features (eg. the way the *info files work) so that they could be trusted; you'd still have to deal with network security issues because now you've made the network and the workstations into the weakest links. That means forcing use of something like SSH or TLS/SSL and providing for ways to manage certificates so that they can be used for authentication. Once you do that then you still have the workstations as the weakest link (which of course they are even with the current use of SSH to access a CVS server). Applications programmers really need to learn to leave security to the OS and learn to deal with whatever limitations that might impose on how they design their systems. As it turns out that's exactly the way CVS was designed in the first place, and how it has been extended to be used in a client/server configuration with RSH/SSH. If you want to use CVS then you have to live with these design decisions. You can hack on some false sense of security if you want but nobody who knows any better is going to want to share that false security with you. -- Greg A. Woods +1 416 218-0098;[EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Per-modules readers/writers ?
The consensus of the maintainers has historically been to never add features that they don't personally need, unless somneone supplies code, documentation, and a regression suite. And then it gets integrated at their discretion. There are already at least two major splinter groups using features that have been rejected for whatever reasons: Those using advisory locks as supplied by Noel Yap, and those using mcvs. --- Forwarded mail from [EMAIL PROTECTED] Well, is it the consensus of the maintainers that they will *never* accept any access control feature patches for CVS? Or is it that if someone is willing to back-port and contribute this from the CVSNT side, they will accept it? I.e. is the opposition to ACLs a matter of priorities, or philosophy? If it is philosophy, is it the position of the maintainers that ACLs are so evil that they will actively oppose any attempt by anyone to insert such a feature into CVS, in order to protect innocent users from this heresy? --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Per-modules readers/writers ?
[ On Tuesday, October 29, 2002 at 10:28:25 (-0800), Shankar Unni wrote: ] Subject: RE: Per-modules readers/writers ? In any case, I'll take a closer look at the CVSNT stuff (I wish they hadn't gone and reformatted all their sources so much :-/), and see what's portable back to the main line.. Some basic features (cvs passwd, cvs ls, etc.) should be easy to backport. Others (ACLs, all the NT-specific stuff, etc.) may be a lot more messy, and probably won't be solid enough to pass muster anyway (so this long argument may be moot, for all you know..) If you're happy without real security then why don't you just move your repository over to M$-NT and run CVSNT? -- Greg A. Woods +1 416 218-0098;[EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Per-modules readers/writers ?
Todd Denniston writes: This is the point where you set down, add up what it will cost your company to support your number of users by putting addons on a ''cheapskates'' version control system to support its use in the companies IP policy setup. For rational values of company, of course. Just asking all these idiotic questions because no one is addressing that point. All I'm seeing are comments along the lines of if your company VPs cannot all take time to sit down and do a top-down reorganization of your IT department to take advantage of CVS as it stands in its purity today, just go away and don't bother us. FWIW, Open Source/Free software is not generally known for providing features to cater to pointy-haired bosses and their policies, or anything that is seen as PHB-created messes. -- Now building a CVS reference site at http://www.thornleyware.com [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Per-modules readers/writers ?
I think this discussion has hit a wall, but I'll answer these points anyway. But I'm no longer pushing for such a feature to be included, because of the obvious reluctance of so many, so we can let this discussion drift away.. Greg Woods wrote: If you're happy without real security then why don't you just move your repository over to M$-NT and run CVSNT? Cost? Utility? Stability? (And besides, is it your contention that Linux filesystem security is real security? All I have to do is break into the machine as root using one of the many unpatched vulnerabilities, and the whole repository is mine..) NT Server costs $$$. Besides, I don't like NT Server very much anyway as a server - a Linux server is far more versatile and solid. In fact, we did start off using CVSNT on an NT box, and after several dozen blue screens and one repository corruption, I gave up on the stupid thing. On the other hand, I can't very well go up to, say, the CIO and tell them that I want the whole company to ditch Microsoft and implement a whole new Grand Unified Authentication and Authorization mechanism across the company. I could, if I wanted to make it my personal full-time evangelism and crusade, but I have to live within real-life constraints. Look, I understand where you come from regarding security, and grafting on security mechanisms on top of each other. On the other hand, what most of us are looking for here are not absolute, drop-dead, guaranteed security, but a mere semblance of an approximation of authorization walls. In most of our environments, we don't have gangs of hostile hackers wandering around looking for things to break into. These are more like little doorlocks that exist merely as an indication to law-abiding employees that the contents are not for them. Certainly there is no intention to make the protection criminal-proof, because that would be enormously difficult. I'm not making my repository public to Joe Random from Little Rock, AK, and I'm not trying to make my repository more secure than my company's overall IT infrastructure. I understand that implementing such a feature may lead someone else to think that that would make CVS secure enough to put it on a public internet with national secrets protected only by this mechanism, but that could be addressed by a warning or something.. For example, pserver isn't really (or even remotely) secure either, and it's there for good or bad, because there's such an *overwhelming* demand and need for it. I know you'd like to rip it out and throw it away, but you'll never hear the end of the screaming if you did so. Still, I hear the reluctance from the faithful, so I'll no longer push for this feature, anyway.. I'll still look to try to back-port non-security-related features where it would be easy and useful.. -- Shankar. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Per-modules readers/writers ?
[ On Tuesday, October 29, 2002 at 13:47:05 (-0800), Shankar Unni wrote: ] Subject: RE: Per-modules readers/writers ? Cost? Utility? Stability? Good questions. What are _your_ answers? (And besides, is it your contention that Linux filesystem security is real security? All I have to do is break into the machine as root using one of the many unpatched vulnerabilities, and the whole repository is mine..) Who said anything about Linux? I certainly didn't. NT Server costs $$$. Besides, I don't like NT Server very much anyway as a server - a Linux server is far more versatile and solid. In fact, we did start off using CVSNT on an NT box, and after several dozen blue screens and one repository corruption, I gave up on the stupid thing. So, which is it? Do you want some level of security, or not? On the other hand, I can't very well go up to, say, the CIO and tell them that I want the whole company to ditch Microsoft and implement a whole new Grand Unified Authentication and Authorization mechanism across the company. I could, if I wanted to make it my personal full-time evangelism and crusade, but I have to live within real-life constraints. You (must) live with the circumstances you create for yourself. Look, I understand where you come from regarding security, and grafting on security mechanisms on top of each other. Well, either you do or you don't. You're still asking to create something that is only an illusion while at the same time not thinking about how you could build your illusion without changing CVS at all. On the other hand, what most of us are looking for here are not absolute, drop-dead, guaranteed security, but a mere semblance of an approximation of authorization walls. Then clearly you do not need or want anything over and above what CVS gives you today with basic unix permissions and ownerships and so on. You already have a mere semblance of an approximation of authorization controls -- and you can implement even more of them too in very simple hooks in the CVSROOT/*info files, with no mods necessary to CVS itself. For example, pserver isn't really (or even remotely) secure either, and it's there for good or bad, Indeed. And for bad only. because there's such an *overwhelming* demand and need for it. I know you'd like to rip it out and throw it away, but you'll never hear the end of the screaming if you did so. You've got that _way_ wrong. 'cvs pserver' was a horrible failed experiment with absolutlely no thought to security or its future bad impact on CVS. It's a stupid hack that really isn't necessary now and never really was. It was only created because the better alternative was (mistakenly) considered to be too difficult. It's only still in CVS because nobody bothered to take it out in time. Even for anonymous read-only access pserver's time has come and gone long long ago. -- Greg A. Woods +1 416 218-0098;[EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Per-modules readers/writers ?
The other (counter-) factor is that in large environments, users are often managed through YP or LDAP (and generally from the IT point of view lumped into a few giant groups like engr and users). These environments are not necessarily paranoid enough to need C2-level security (which is another nightmare to administer), but often do need to implement a coarse level of read/write control over modules for users. Also, even if a finer level of groups were implemented at the YP level, it's then hard to give access to a module to *one* user from an outside group without sticking them into that group at the YP level (and thus opening up that entire group's resources to them, instead of just the one module in the one repository). Independent CVS-maintained repository-level group management and access control is very useful in such environments. David R. Chase wrote: I suppose it comes down to how you identify actual users, since the system has to know somehow about who is trying to access a module in order to allow or deny that access. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Per-modules readers/writers ?
[ On Monday, October 28, 2002 at 09:14:41 (-0800), Shankar Unni wrote: ] Subject: RE: Per-modules readers/writers ? The other (counter-) factor is that in large environments, users are often managed through YP or LDAP (and generally from the IT point of view lumped into a few giant groups like engr and users). It doesn't really matter where the account data is managed and supplied from. There are litterally hundreds of ways to integrate centrally managed account information with unix and unix-like systesm. The point is that the Unix system security model mandates that every unique human user (as well as unique system identities) have a unique system account. You cannot even get basic unix security without using its concept of accounts. These environments are not necessarily paranoid enough to need C2-level security (which is another nightmare to administer), but often do need to implement a coarse level of read/write control over modules for users. C2-level security is just an example to show how much you really have to do to achieve any useful amount of accountability. Even basic unix security requires proper use of individual system accounts. -- Greg A. Woods +1 416 218-0098;[EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Per-modules readers/writers ?
Greg A. Woods writes: Even basic unix security requires proper use of individual system accounts. Absolutely. No argument there. The issue I was talking about was not authentication, but access control (authorization), using Unix accounts. Authentication using Unix accounts is A-OK. (Use YP, LDAP, whatever..). Authorization, on the other hand, is also still being left to the same mechanism (YP or whatever), which is rather too coarse and inflexible (see the arguments I put forward..) I see that the CVSNT folks are adding CVS-level ACLs (access control lists), using hidden .perms and .owner files in repository directories that contain files. Should probably take a deeper look at how they implement this, and how it ties to various authentication mechanisms like :pserver: .. -- Shankar. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Per-modules readers/writers ?
[ On Monday, October 28, 2002 at 12:02:33 (-0800), Shankar Unni wrote: ] Subject: RE: Per-modules readers/writers ? Greg A. Woods writes: Even basic unix security requires proper use of individual system accounts. Absolutely. No argument there. The issue I was talking about was not authentication, but access control (authorization), using Unix accounts. Authentication using Unix accounts is A-OK. (Use YP, LDAP, whatever..). Authorization, on the other hand, is also still being left to the same mechanism (YP or whatever), which is rather too coarse and inflexible (see the arguments I put forward..) It's all part of the same thing. In computer security you can't have any accountability without authorisation, and to do authorisation you have to have strong authentication, and to have any level of any of the above you have to have at least an equivalent level of system integrity protection too. So, no matter what you want to do with access control you still have to base it on these fundamental system supplied services, if you want to actually have any significant level of trust in your system security. CVS uses a one-to-one mapping files to store change history per source file and the access controls usable with CVS are based entirely on granting different levels of access to the directories those version history files are stored in. If you want finer control then you either need to break appart your modules so that the existing accounts and groups mechanisms can provide the necessary degree of refinement, perhaps with multiple role accounts for each user; or maybe you can to arrange things such that you can use C2-style filesystem ACLs on the directories in the repository, provided you build your repository on a system with the necessary support for filesystem ACLs (and provided you're ready to do all the extra maintenance on such ACLs). With CVS you simply cannot possibly have any secure control over branches or tags or individual revisions because all those things are part of the internal structure of the version history files. CVS is not like bare RCS or SCCS -- you cannot securely implement a setuid or setgid wrapper around it so that it can take over control of authorisation. Even with bare RCS or SCCS the use of set-id wrappers is highly suspect and often easily bypassed by a malicious user. Computer systems security doesn't exist just inside the box -- you have to apply security policies out in the real world too, and its usually those real-world policies that have the most clout. If you want to stop certain users from changing certain branches or tags then make it a firing offense to do so under your overall security policy and make sure that you have implemented good strong system security so that you can back up your finger pointing with hard evidence and thus be able to fire the right person whenever they do something wrong. The technical control in this case is a potentially mechanized audit that reveals the unauthorised actions of any user. The recovery and punishment are implemented outside the system by manual procedures. I see that the CVSNT folks are adding CVS-level ACLs (access control lists), using hidden .perms and .owner files in repository directories that contain files. Should probably take a deeper look at how they implement this, and how it ties to various authentication mechanisms like :pserver: .. You're welcome to -- just try not to be fooled into thinking you're actually getting any level of enhanced or more flexible security in return because you would not be. -- Greg A. Woods +1 416 218-0098;[EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Per-modules readers/writers ?
Greg Woods writes: It's all part of the same thing. In computer security you can't have any accountability without authorisation, and to do authorisation you have to have strong authentication [...] Again, I agree with you on the principle. It makes perfect sense. On the other hand, from a purely practical point of view, many repository are trying to put in *some* level of control without having to set up a full C2-style access control mechanism. Sure, it's not perfect, but it's adequate in most situations (this is a judgement call, and involves a resources vs security tradeoff). I'm sure you've seen typical corporate IT setups - everything is broken up into departments, and the network administrators don't necessarily cooperate with the domain administrators, who don't in turn work too closely with the repository administrators. This makes it hard for the repository administrator to put in a level of access control without having to spend days or months running after the other departments, and genuflecting in front of the change review boards. Other competitive source-code control systems have such informal mechanisms in place that are trivial to administer, _for the person who is responsible for maintaining the repository_, and it's generally in response to overwhelming customer demand. -- Shankar. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Per-modules readers/writers ?
[ On Monday, October 28, 2002 at 13:44:50 (-0800), Shankar Unni wrote: ] Subject: RE: Per-modules readers/writers ? This makes it hard for the repository administrator to put in a level of access control without having to spend days or months running after the other departments, and genuflecting in front of the change review boards. Version control is a part of software configuration and change management. I thought that (what you said) is what it (change management) was all about! ;-) Other competitive source-code control systems have such informal mechanisms in place that are trivial to administer, _for the person who is responsible for maintaining the repository_, and it's generally in response to overwhelming customer demand. I think you're still missing the point. CVS is a _very_ _simple_ version control tool that is built entirely upon RCS and it does very little on its own except make some repetitive tasks easier, and provides some hooks where various procedures can be integrated into these tasks. RCS uses normal Unix files and filesystem protections, providing only for directory level access control through the normal underlying filesystem access controls of who can read (and search in) a directory and who can write to that directory. There's no access control possible, not even theoretically, for any of the internal structure of an RCS file -- anyone who can write to the directory containing the file can change any content of the file. Those other competitive (*) source code control systems are either promising things they simply cannot possibly deliver securely, or they have fundamentally different underlying repository designs. (*) open source tools like CVS do not compete for market share and their developers and maintainers have very little incentive to provide features which customers demand if those same features are not also directly of use to the developers and maintainers, especially when such features demand a ground-up re-design of the whole thing. If you think some so-called competitive tool is better suited for your requirements then you really should use it instead of CVS -- CVS isn't meant to be the one tool that meets everyone's needs! Even if you paid someone (such as myself ;-) to re-design and develop a variant of CVS to make it do what you want it to there's no guarantee that it would replace CVS or even be embraced by other CVS users. -- Greg A. Woods +1 416 218-0098;[EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Per-modules readers/writers ?
Greg A. Woods wrote: Version control is a part of software configuration and change management. I thought that (what you said) is what it (change management) was all about! ;-) Argh. I don't think I'm getting my point across, am I? OK, forget I said change management. The problem is that I (the repository administrator) often have *NO CONTROL* over how the system YP entries and groups are set up, because it's controlled and decided by some bureaucrats sitting 3000 miles away in an air-conditioned control room. Worse, it's often some gruesome hack on top of a Windows domain or something like that.. If this (Unix-level access control) is the only way available for me to control access to files, I am UNABLE to implement any access control at all. Look, we all want to use CVS, because it's free. I agree, we're all weaselly cheapskates who want everything for nothing :-). I merely pointed out the competitive thingys to make the point that others are doing this, _because it has been repeatedly asked for_ by customers who face such problems every day. What I'm asking is whether anyone is interested in the sort of ACL work being done on the CVSNT fork (about which I asked earlier: has it truly forked for good, then?), and which I haven't examined in a great amount of detail yet, but which seems promising. YES, I understand that its security is not perfect. It's a lot better than not having any damned control at all. After all, I don't have hostile hackers roaming the halls and my network trying desperately to work around the security in CVS. Heck, if I have hostile hackers loose in my network, I have a *@#$load of more problems than whether they can read a particular source file.. Or is the philosophical opposition to such grafted-on mechanisms so great here that no one is ready to even consider any sort of feature in CVS that might dare whisper of the access control heresy? (I see a lot of mention of Unix this and Unix that. Problem is, this is used in a lot of environments which aren't even Unix. At least, the clients often aren't Unix. For instance, the most common Java development configuration out there is a Linux server and Windows clients, because Sun's JDK on Windows runs rings around Sun's JDK on Linux and even Solaris. Go figure..) -- Shankar. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Per-modules readers/writers ?
Please unsubscribe me. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Per-modules readers/writers ?
There's a lot to be said for denying all users the ability to log in to a critical application server (i.e. not giving them accounts), and then connecting the applications up to sockets and letting them do their own user authentication and access authorization. This is particularly true if you need to grant access to data in ways that don't map well to the access control mechanism supplied with the operating system. And if the authentication is strong (it can even be stronger than what the OS supports) then all of the arguments against using such mechanism lose their strength; by virtue of passing a difficult test points accountability to the right users. The drawback is that there's central user database. This is also a compelling feature to support data sharing across multiple critical applications. --- Forwarded mail from [EMAIL PROTECTED] YES, I understand that its security is not perfect. It's a lot better than not having any damned control at all. After all, I don't have hostile hackers roaming the halls and my network trying desperately to work around the security in CVS. Heck, if I have hostile hackers loose in my network, I have a *@#$load of more problems than whether they can read a particular source file.. Or is the philosophical opposition to such grafted-on mechanisms so great here that no one is ready to even consider any sort of feature in CVS that might dare whisper of the access control heresy? --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Per-modules readers/writers ?
Wow, I guess we bored at least one reader to tears :-).. -Original Message- From: Shabbir Poonawala [mailto:zaini;nagpur.dot.net.in] Sent: Monday, October 28, 2002 6:13 PM To: 'Paul Sander'; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: Per-modules readers/writers ? Please unsubscribe me. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Administrivia -- RE: Per-modules readers/writers ?
On Mon, 28 Oct 2002, Shankar Unni wrote: Wow, I guess we bored at least one reader to tears :-).. -Original Message- From: Shabbir Poonawala [mailto:zaini;nagpur.dot.net.in] Please unsubscribe me. Even sadder, Shabbir was not even subscribed under that email address. As a list maintainer, in administering the bounces, I get a lot of pieces which are running through intermediate forwarders, and cannot be traced back, due to header stripping. I have just read that Mailman can be used to produce a Majordomo type roster of users, by email request (necessary, as I do not have shell access to the Mailman host) -- If I can get that roster (a couple thousand names), I will issue a serialized vacation tracer to each user, and weed some stale accounts out. -- Russ Herrold ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Per-modules readers/writers ?
On Thu, Oct 24, 2002 at 04:49:08PM -0400, David R. Chase wrote: Hello there, I'm mainly trying to obtain finer granularity access control via pserver (or other remote access) authentication rather than via the filesystem's uid/gid and related permissions. What's wrong with uid/gid based permissions? /npat -- A commune is where people join together to share their lack of wealth. -- Richard M. Stallman ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Per-modules readers/writers ?
Nick Patavalis wrote: What's wrong with uid/gid based permissions? For starters, they require that each CVS user have a login account on the machine in question. In some cases, this is not acceptable. /|/|ike ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Per-modules readers/writers ?
Nick Patavalis wrote: What's wrong with uid/gid based permissions? For starters, they require that each CVS user have a login account on the machine in question. In some cases, this is not acceptable. Assuming that you don't let them log in using it (and that's not difficult), why would it be unacceptable? Moreover, how do you expect to get any accountability without having separate user accounts, and why would readers/writers work any better than uid/gid without separate accounts? -- Now building a CVS reference site at http://www.thornleyware.com [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Per-modules readers/writers ?
- Original Message - From: [EMAIL PROTECTED] To: Mike Ayers [EMAIL PROTECTED] Cc: Nick Patavalis [EMAIL PROTECTED]; David R. Chase [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, October 25, 2002 1:59 PM Subject: Re: Per-modules readers/writers ? Nick Patavalis wrote: What's wrong with uid/gid based permissions? For starters, they require that each CVS user have a login account on the machine in question. In some cases, this is not acceptable. Assuming that you don't let them log in using it (and that's not difficult), why would it be unacceptable? Moreover, how do you expect to get any accountability without having separate user accounts, and why would readers/writers work any better than uid/gid without separate accounts? Sorry about the direct email -- clicked the wrong button for replying to the list. : ) It's probably not any better, more like an alternate feature that would be handy in certain environments. Personally, I'd rather the repository be owned and operated by just one user, and allow the repository administrator to be able to grant and revoke permissions and add new projects and project groups without having to add any users/groups to the system. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Per-modules readers/writers ?
Nick Patavalis wrote: It's probably not any better, more like an alternate feature that would be handy in certain environments. Personally, I'd rather the repository be owned and operated by just one user, and allow the repository administrator to be able to grant and revoke permissions and add new projects and project groups without having to add any users/groups to the system. I suppose it comes down to how you identify actual users, since the system has to know somehow about who is trying to access a module in order to allow or deny that access. The classic Unix method is to assign each actual user an account on the machine, and this authentication method has been worked on extensively, both to try to improve it and to try and stop people spoofing it. It's about as secure a means as you can get, at least when you use known secure techniques. Any other method of authentication is going to be easier to fool. CVS's pserver is a case in point: it isn't secure, and if you want strict authentication you should use :ext: with ssh or some such thing. Not only has there been less work done on securing it, but there never will be anywhere near as much work. If security is an issue, you want to enforce authentication, since no security is perfect and you need to have some sort of audit facility. Therefore, you want as reliable a method of authentication as possible, and I don't know of anything better than Unix user accounts. There's security there, if people use it. -- Now building a CVS reference site at http://www.thornleyware.com [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Per-modules readers/writers ?
[ On Friday, October 25, 2002 at 19:25:43 (-0500), [EMAIL PROTECTED] wrote: ] Subject: Re: Per-modules readers/writers ? If security is an issue, you want to enforce authentication, since no security is perfect and you need to have some sort of audit facility. Therefore, you want as reliable a method of authentication as possible, and I don't know of anything better than Unix user accounts. There's security there, if people use it. Just to continue on a little further: Note too that even better auditing (and thus accountability) and access control can be had by using one those systems which have been enhanced to be able to meet the Orange Book C2-style security classification. C2 requires mandatory access controls on all filesystem objects and much more detailed audit trails for all accesses of those objects. Those kinds of things can never be done at the application level, at least not on a general-purpose computing platform. -- Greg A. Woods +1 416 218-0098;[EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Per-modules readers/writers ?
Hello there, Searched some of the archives but came up empty. I don't think it's supported, but I'm mainly asking to see if this will ever be implemented in the future. Basically, I'm wondering if there's any way to limit read/write access to a repository on a modular level, that is, some users mapped in $CVSROOT/CVSROOT/passwd will have read or write access to some modules, while other users will have it for others. I'm mainly trying to obtain finer granularity access control via pserver (or other remote access) authentication rather than via the filesystem's uid/gid and related permissions. With a fairly large repository, administration of large groups of users for a large number of modules can become a nightmare if done on the filesystem level without ACLs. I'd rather have one system user that a great number of developers are mapped to as virtual users, rather than creating a new user or group for each project's members to access the repository with. If not, and I wanted to write a patch to add this feature, what would be the best way to do it? Have module-permissions defined in $CVSROOT/CVSROOT/ [readers,writers] or have permissions defineable in each module directory such as $CVSROOT/module-name/config-dir/[readers,writers] ? (personally, I believe the second choice reduces overhead as the lookups could be done on modular files rather than the global readers/writers files which could tend to become very large). Unless, of course, there's a better way to do what I want it to do, and not on the filesystem level... : ) Thanks in advance, David R. Chase College of Computer Science Northeastern University, Boston ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Per-modules readers/writers ?
If not, and I wanted to write a patch to add this feature, what would be the best way to do it? My two bits...move CVSROOT and all its contents into normalized SQL tables. Not a trivial patch, but it would open up whole new doors for manipulating, querying, and accessing the repository (not to mention transactions and triggers!) Yes, this would likewise close some doors for those who like direct access to the raw RCS metadata files. But anyone conversant in sed or perl should have little trouble mastering SQL, anyway... /troll -Mark Z ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Per-modules readers/writers ?
David R. Chase writes: Basically, I'm wondering if there's any way to limit read/write access to a repository on a modular level, that is, some users mapped in $CVSROOT/CVSROOT/passwd will have read or write access to some modules, while other users will have it for others. I'm mainly trying to obtain finer granularity access control via pserver (or other remote access) authentication rather than via the filesystem's uid/gid and related permissions. With a fairly large repository, administration of large groups of users for a large number of modules can become a nightmare if done on the filesystem level without ACLs. I'd rather have one system user that a great number of developers are mapped to as virtual users, rather than creating a new user or group for each project's members to access the repository with. I strongly suggest using the filesystem's uid/gid and related permissions. Assign a group for each set of modules that require the same access permissions, assign a unique uid to each user (for traceability), and assign each user to as many groups as necessary. If not, and I wanted to write a patch to add this feature, what would be the best way to do it? Have module-permissions defined in $CVSROOT/CVSROOT/ [readers,writers] or have permissions defineable in each module directory such as $CVSROOT/module-name/config-dir/[readers,writers] ? (personally, I believe the second choice reduces overhead as the lookups could be done on modular files rather than the global readers/writers files which could tend to become very large). This is a very bad idea -- CVS is a version control system, not a security system. Using it to implement security is a sure route to exploitable vulnerabilities (witness pserver). -Larry Jones I hope Mom and Dad didn't rent out my room. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
