[ 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"
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
> 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 "compan
[ 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&#x
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
[ 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
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",
Shankar Unni writes:
>
> 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
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
::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 wee
Shankar Unni wrote:
>
> 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 sa
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
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
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 nee
Please unsubscribe me.
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
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 t
[ 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 d
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
[ 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 is
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, L
[ 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 i
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
[ 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. Therefo
>
> > > 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
- 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
Sub
> 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
diffic
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
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 ba
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 t
> 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
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
31 matches
Mail list logo
