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.)
-jason
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
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