[ale] Permissions Q

[Mike Millson]

What is meant by a 'no login' account? Is this an account created with the
useradd -r option where the account doesn't have a home directory? Just an
account that people su to but never log in as?

-----Original Message-----
From: John Mills [mailto:jmmills at telocity.com]
To: ale at ale.org
Sent: Thursday, June 13, 2002 1:25 PM
To: ALE
Cc: Michael Hirsch; Mike Millson
Subject: Re: [ale] Permissions Q


Michael -

On 13 Jun 2002, Michael Hirsch wrote:

Thanks for filling in my missing link. Once again, an ALEr comes up with
the key that a specialized mailing list couldn't find.

> On Thu, 2002-06-13 at 10:47, John Mills wrote:

> >  I created a user 'cvsmgr' who belongs to 'cvsusers' and who owns
> > $CVSROOT, its children, and its contents.
> >  I put all developers in $CVSROOT/CVSROOT/passwd, with their choice of
> > trivial or null passwords, and all with the CVS user-identity of
'cvsmgr';
> > and one read-only user, 'buildusr', with null password and no other
> > identity.

> >  I created a group 'cvsusers' and added all developers, 'cvsmgr', and
> > 'buildusr' to that group.

> There is two more steps.  execute 'chgrp -R cvsusers $CVROOT' so that
> all files and dirs are owned by the cvsusers group.  Also, execute
> 'chmod g+s $CVSROOT'.  If $CVSROOT already has subidrectories, run
> 'chmod g+s' on all those subdirs.

Since I have only one group of users, I'll just go above the repository
root and do:

# chmod g+s `find <repository_root> -type d -print`

and hit all the subs at one go.

 - John Mills

On Thu, 2002-06-13 at 10:47, John Mills wrote:
> Hi, Mike -
>
> On Wed, 12 Jun 2002, Mike Millson wrote:
>
> > Ex. 1
> > ========================================
> > I have a CVS repository that is currently owned by root and its group is
> > root. What is the best way to allow users access? Should I leave the
Owner
> > and Group as root and allow Others read and write access? Should I
create a
> > new group that is specifically for CVS, give it read and write
privileges
> > and add each user to it?
>
> I assume you are working through :pserver: or a secure equivalent. I am
> just setting up a CVS repository for a development team working on many
> files (~1500) of a new product. Here's what I did:
>
>  I created a user 'cvsmgr' who belongs to 'cvsusers' and who owns
> $CVSROOT, its children, and its contents.
>  I put all developers in $CVSROOT/CVSROOT/passwd, with their choice of
> trivial or null passwords, and all with the CVS user-identity of 'cvsmgr';
> and one read-only user, 'buildusr', with null password and no other
> identity.
>
>  I created a group 'cvsusers' and added all developers, 'cvsmgr', and
> 'buildusr' to that group.

There is two more steps.  execute 'chgrp -R cvsusers $CVROOT' so that
all files and dirs are owned by the cvsusers group.  Also, execute
'chmod g+s $CVSROOT'.  If $CVSROOT already has subidrectories, run
'chmod g+s' on all those subdirs.

Now anyone in the group can read and write to those subdirs, thanks to
'chgrp'.  The 'chmod g+s' makes it so that any new files/dirs are also
owned by the cvsusers group.

There was a recent article in the IBM developer area about just this
trick.

--Michael

>
> NOTE:
> System accounts must _exist_ for all these CVS users, but they can be
> 'nologin' accounts.
>
> So far the only wrinkle I've seen is this: when a user creates a new
> _directory_ in the CVS repository, it gets the permissions: 'drwxrwxr-x'
> and cannot be used (even for checkout) by any other user until the
> permissions have been changed to 'drwxrwxrwx'. I would like these to be
> the default permission settings for new directories in CVS, but haven't
> been able to manage it. Naturally for many organizations the current
> defaults are correct.
>
> New files' permissions default to '-r--r--r--' which is _correct_ (except
> for executables, which need '-r-xr-xr-x'). 'Apparent' ownership of files
> and directories in $CVSROOT is 'cvsmgr', which is correct.
>
> HTH.
>
>  - John Mills


---
This message has been sent through the ALE general discussion list.
See http://www.ale.org/mailing-lists.shtml for more info. Problems should be 
sent to listmaster at ale dot org.