SPUG: setuid & CGI security

Jason Lamport jason at strangelight.com
Tue Jun 26 12:12:34 CDT 2001

At 8:37 AM -0700 6/26/01, El JoPe Magnifico wrote:
>It's not an optimal solution, and only provides read protection,
>no write protection, but you can easily encrypt the data files.
>The Crypt::* modules are fun 'n easy.

How do you decrypt them without making the decrypting password world-readable?

>Another hacky workaround that would give you both read and write
>protection (though the security soundness is questionable), is to
>write a separate prog outside in your document root through which
>your CGI script accesses specific files, have it require an auth
>token at the start,

Again: any auth token that the CGI can access can also be accessed by 
any other user on the system.

At 11:39 PM -0700 6/25/01, William Julien wrote:
>An interesting perpective. For the sake of protecting a few select files
>from writing by local users (remember, regular html files still need
>a permission of 644 and thus are still available for global viewing), it
>seems your are more comfortable exposing *all* files to world read/write
>access to a larger anonymous web community. Hmmm.

Huh?  Explain to me how I am "exposing *all* files to world read/write"?

>Also, knowledge of the local userid is protected since the /home directory
>is resticted from browsing (surfing) by local users. The virtual
>domain definition hides the owning userid of the domain. Therefore,
>it is difficult for a local or remote user to know that which userid is
>associated to a domain, unless provided within the context of the page
>(guilty). Given just my domain name, catmanor.com, you would have no
>way to know the maintanence userid.

While I agree that it is prudent not to publish one's userid (no 
sense giving hackers any more information than is absolutely 
necessary) any setup that relies exclusively on keeping one's userid 
secret seems to me to be a very poor choice. The basic security model 
of Unix (and most other systems) is that the userid (which is usually 
fixed) is public and the password (which can usually be changed at 
will) is private.  Simply knowing a person's user name should *not* 
allow one to gain access to their private files!

(And BTW, a quick scan of likely usernames on drizzle's system just 
now turned up several hits in just a couple of minutes.)


 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
     POST TO: spug-list at pm.org       PROBLEMS: owner-spug-list at pm.org
      Subscriptions; Email to majordomo at pm.org:  ACTION  LIST  EMAIL
  Replace ACTION by subscribe or unsubscribe, EMAIL by your Email-address
 For daily traffic, use spug-list for LIST ;  for weekly, spug-list-digest
  Seattle Perl Users Group (SPUG) Home Page: http://www.halcyon.com/spug/

More information about the spug-list mailing list