RE: [cobalt-developers] Re: CGI Wrap Errors

[Keith Vance <keithv@xxxxxxxx>]

I need you to unsubscribed from this list. Can you do that?

-----Original Message-----
From: Robert G. Fisher [mailto:rfisher@xxxxxxxxxxxxxxx]
Sent: Wednesday, May 24, 2000 8:19 AM
To: cobalt-developers@xxxxxxxxxxxxxxx
Subject: Re: [cobalt-developers] Re: CGI Wrap Errors


On Tue, May 23, 2000 at 06:26:16PM -0700, Will DeHaan wrote:
> On the web or in a shell?  What does it matter?  If a user wants to keep
> sensitive data web accessible, they shouldn't store that data in a web
> accessible location!  CGI-wrap will enable them to store such things in
> more restrictive locations such as a subdirectory from the site or user
> home directory.

    While my first thought is to agree with you Will, there are 
a few cases where these concerns can be valid.  Thankfully, the 
RaQ2 at least implemented shadow passwords which was high on the 
list.
    The largest concern of things inside a public web space are the 
'password protected areas' generally reserved for paying members and
the htpasswd style files protecting these areas.  While the concept
of passwords in the clear as a world readable file may sound ludicrous
to you, keep in mind this isn't too far from what the bulk of 
.htpasswd files are such as the service.pwd and so forth.  Since 
it requires root access to chown these files to httpd so world 
readership bits can be removed -- it means something the users can't 
do on their own.
    There's also the matter of the service.pwd file and so forth,
for some (as yet inexplicable but somehow not astonishing) reason
the _vti_* files which are created by the root account using
fpseradm.exe all are owned by httpd and the site group but then have
public read (and execute) permissions...  Which is unneccessary, but
then, if security is a real concern for someone they shouldn't be
using FP SERK IMHO.

> You probably want chroot'd telnet access and don't want to mess with
> file permissions.  Has anyone got this working on the RaQs?  It can be
> done with a big slew of hard links or with a ~22MB/site penalty for
> copied files, in addition to changing users shell.

    Off the top of my head I'm having trouble thinking of any shell
that provides an easy way to call chroot(2) and chroot(1L) requires
root permissions to be run at startup, and pam_chroot seems to be
nowhere in sight that I'm aware of.  The login no longer supports
the SRV4 convention of a '*' being cause for a call to chroot either
so *shrug*.

-- 
Robert G. Fisher		     NEOCOM Microspecialists Inc. 
System Administrator/Programmer      (540) 666-9533 x 116

_______________________________________________
cobalt-developers mailing list
cobalt-developers@xxxxxxxxxxxxxxx
http://list.cobalt.com/mailman/listinfo/cobalt-developers