Re: [cobalt-users] Restricting Users

[Kris Dahl <krislists@xxxxxxxxxxxxx>]

on 5/18/00 3:14 PM, J at jjma@xxxxxxxxxxxxxx wrote:

> 
> I have eight different users that have to be given access to a site recently
> created with none of them set-up as site admin and each with a different
> level of ability and experience. Each users is in charge of one page on the
> site. I though at first  to set-up separate folders for each group so that
> any further additional pages would be assigned to that folder rather than
> having the possibility of a user overwriting another's file (links.htm). I
> would ideally like to restrict their FTPing to their own personal folder
> cutting out the chance of meddling or corrupting the site as well as giving
> the site admin total control of all the site.
> 
> Is there a way that this could be set-up, I don't really want the situation
> now where in order to see each users file you have to type
> http://www.site.co.uk/users/surf/ , as it looks unprofessional.

Sounds like what you really need is a content management system.  These are
the sorts of problems that we deal with on a regular basis here at
Toolhouse.

The way we commonly get around these sorts of problems is the same way the
even bigger sites do it...

Kris's Guidelines for Big Web Sites

Rule #1
You have a three tier system for starters: development, test/qa, and a
production server ).
These don't necessarily (although ideally...) have to be on separate
machines.  They do, however, have to be separate virtual hosts to work
properly.  You never want more than one person tinkering with a live site at
once--in fact you don't want anyone tinkering with a live site period.  The
live site should be 'replicated' from the Test server.

Rule #2
You should have a content management system.  Honestly, content shouldn't be
in the code.  Content that needs to be updated should be abstracted--stored
in a database typically, although XML is now providing this as well.  Tools
can be purchased to do this (Expressroom comes to mind).  We tend to build
these tools for each client, building upon a common code-base.  By setting
up security levels/privileges we enable (for example) the marketing people
to maintain press releases, etc., the HR people to manage employment
listings, etc.  The right people manage the correct content--and don't risk
taking the site down or losing content if someone makes a mistake.  You also
can audit changes and do rollbacks, etc.

It sounds like overkill, but really isn't that hard to do.  If you're
serious about the website (or perhaps I should rephrase-if you're web site
is important and needs to be managed by multiple people), you probably
should be thinking about implementing this sort of system.  It will save you
mucho headaches in the lon run.


But if you want to manage the security of files on a Linux machine, just set
up multiple groups and give the group read/write/execute.

i.e
marketing: bill, bob, god
hr: joey, jill, god
masteradmins: god

Then set the group to the files you're talking about to the group you need.
The owner you can set to one of the master admin's.

ie, as a currentsite admin and owner of the file:
chown god.hr employment.htmld

then give the group (second digit) read and write access (6).
chmod 664 employment.html

Should work, however, you can go cross-eyed pretty quick if it is very
complex.

-k