[pmwiki-users] Re: Re: Calendar recipy

Menachem Shapiro menachem.shapiro at gmail.com
Fri Feb 11 11:31:08 CST 2005


B"H

This great explaination should probably be added to the documentation,
maybe on this page:
http://www.pmwiki.org/wiki/PmWiki/Installation

Menachem

On Thu, 10 Feb 2005 16:12:06 -0600, Patrick R. Michaud
<pmichaud at pobox.com> wrote:
> On Thu, Feb 10, 2005 at 09:44:37PM +0100, chr at home.se wrote:
> > On Thu, 10 Feb 2005, Patrick R. Michaud wrote:
> >
> 
> First, let's look at PmWiki 2 without any cookbook scripts loaded.
> PmWiki needs to be able to write into the wiki.d/ directory to be
> able to save pages.  And it needs to be able to write into the uploads/
> directory to save uploads.  Those are the *only* directories
> that need to be writable by the webserver.  It doesn't matter to PmWiki
> who owns or creates those directories, as long as it has write
> permission to them.
> 
> All other directories should be owned by the account holder, and be
> accessible by the webserver (but normally not writable by the webserver).
> 
> That's it -- everything else depends on the specific PHP configuration
> and running environment, which I'll detail below (and which is why I
> can't give you a definitive answer that is going to apply to every
> situation).  But the above two rules are absolute and answer 95% of
> the questions about directories.
> 
> In the present example of "What ownerships should a pub/css/
> directory have?", we simply ask "Does PmWiki need to create files
> in that directory?"  The answer is "no", so the directory can (should)
> be owned by the administrator and only have basic read permissions (r-x)
> to the webserver.  This means PmWiki shouldn't be responsible for creating
> the directory, because then the webserver would own the directory and not
> the administrator.
> 
> Okay, with that out of the way, here are some configuration specific
> details.  If someone is on a Unix host, then the webserver typically
> runs with a userid and groupid that is different from the account holder
> (e.g, "apache", "www", or "httpd").  Thus, if the account holder creates
> the wiki.d/ and uploads/ directories, then they must also to set the
> directories to be world-writable (rwx) permissions in order for PmWiki
> (running as the webserver account) to create files there.
> 
>    $ pwd
>    /home/pmichaud/public_html/pmwiki
>    $ mkdir uploads
>    $ mkdir wiki.d
>    $ chmod 777 uploads wiki.d
>    $ ls -ld . uploads wiki.d
>    drwxr-xr-x   12 pmichaud pmichaud     1024 Feb 10 11:51 .
>    drwxrwxrwx    8 pmichaud pmichaud     1024 Jan 23 11:58 uploads
>    drwxrwxrwx    2 pmichaud pmichaud    54272 Feb 10 15:29 wiki.d
> 
> However, lots of people don't like having those world-writable (rwx)
> permissions on directories.  Thus, one way to get around that is to let the
> webserver own the directory directly, so that world-writable permissions
> aren't needed to save files there.  However, most unix systems don't
> allow normal users to change file ownerships, so the way to get the
> webserver to own the directories is to let PmWiki create them, by
> temporarily granting write permissions to the parent and then
> running the pmwiki.php script to create the needed directories:
> 
>    $ pwd
>    /home/pmichaud/public_html/pmwiki
>    $ chmod 777 .
>    $ ls -ld .
>    drwxrwxrwx   12 pmichaud pmichaud     1024 Feb 10 11:51 .
>    # <-- execute pmwiki.php script from web browser -->
>    $ ls -ld . uploads wiki.d
>    drwxrwxrwx   12 pmichaud pmichaud     1024 Feb 10 11:51 .
>    drwxrwxr-x    8 apache   apache       1024 Jan 23 11:58 uploads
>    drwxrwxr-x    2 apache   apache      54272 Feb 10 15:29 wiki.d
>    $ chmod 755 .
>    $ ls -ld . uploads wiki.d
>    drwxr-xr-x   12 pmichaud pmichaud     1024 Feb 10 11:51 .
>    drwxrwxr-x    8 apache   apache       1024 Jan 23 11:58 uploads
>    drwxrwxr-x    2 apache   apache      54272 Feb 10 15:29 wiki.d
> 
> This eliminates the world write permissions and leaves things so
> that PmWiki can write the files it needs, but it now unfortunately means
> that the account owner (pmichaud) cannot delete or modify the files
> in those directories.  To get around this, we instead take advantage of
> unix's setgid bit (2777 or "rws" permissions):
> 
>    $ pwd
>    /home/pmichaud/public_html/pmwiki
>    $ chmod 2777 .
>    $ ls -ld .
>    drwxrwsrwx   12 pmichaud pmichaud     1024 Feb 10 11:51 .
>    # <-- execute pmwiki.php script from web browser -->
>    $ ls -ld . uploads wiki.d
>    drwxrwsrwx   12 pmichaud pmichaud     1024 Feb 10 11:51 .
>    drwxrwsr-x    8 apache   pmichaud     1024 Jan 23 11:58 uploads
>    drwxrwsr-x    2 apache   pmichaud    54272 Feb 10 15:29 wiki.d
>    $ chmod 755 .
>    $ ls -ld . uploads wiki.d
>    drwxr-xr-x   12 pmichaud pmichaud     1024 Feb 10 11:51 .
>    drwxrwsr-x    8 apache   pmichaud     1024 Jan 23 11:58 uploads
>    drwxrwsr-x    2 apache   pmichaud    54272 Feb 10 15:29 wiki.d
> 
> Now the two directories are owned by apache and we don't have world-
> writable permissions on them, but pmichaud still has write permissions
> to the files and directories by virtue of the group ownership and
> permissions.  The setgid bit also ensures that any files or
> subdirectories created within uploads/ or wiki.d/ will belong to
> the same (pmichaud) group.
> 
> HOWEVER, if a site is running in PHP's "safe_mode", then the
> "let PmWiki create the directories" solution doesn't work, as
> PHP will only create files in directories that are owned by the
> same user that owns the pmwiki.php script itself.  Thus, PmWiki
> (apache) cannot create the directories in this case, or safe_mode will
> complain when PmWiki attempts to write a file into those directories.
> The *only* way for things to work in safe_mode is to manually create the
> needed directories and set their permissions to 777, as outlined
> at the beginning of this section.
> 
> And for those select webservers/PHP installations that are configured
> such that the PmWiki script runs with the same identity as the
> account holder, then everything "just works" without doing anything
> manually.  PmWiki creates any directories as needed (each owned by
> the account holder), and permissions aren't generally an issue at all.
> 
> Okay, now let's look at cookbook scripts.  If a cookbook script has
> files that it wants to make available to browsers, such files should
> generally be placed somewhere within the 'pub/' hierarchy and referenced
> via '$PubDirUrl'.
> 
> If a cookbook recipe needs to *write* files to disk, then the
> same rules apply to that directory as for the wiki.d/ and uploads/
> directories above, with the exact ownerships and permissions
> depending on the webserver and PHP configuration.  In general
> the cookbook recipe should do the same as PmWiki, and just call
> PmWiki's mkdirp($dir) function.  PmWiki will then take care of creating
> the directory (if it can) or prompting for its creation as appropriate.
> 
> For example, if cookbook recipe 'frobot' wants to distribute a .css
> file, then that file should go somewhere like pub/css/frobot.css or
> pub/frobot/frobot.css.  The directories and files in this case should
> be created and owned by the account owner, since the cookbook recipe
> doesn't need to create or modify any of the files when it runs.
> 
> As an alternate example, the MimeTeX recipe wants to be able to create
> cached images for the math markup, and those images need to be
> available to the browser.  Thus, MimeTeX uses a pub/cache/ directory,
> which should be created in whatever manner was used to create the
> wiki.d/ and uploads/ directories (i.e., according to the webserver and
> PHP configuration).  Again, MimeTeX just solves this by calling
> mkdirp("pub/cache"), and letting that function create the directory
> or prompt the administrator for the appropriate action based upon
> the server settings encountered.
> 
> Pm
> _______________________________________________
> pmwiki-users mailing list
> pmwiki-users at pmichaud.com
> http://pmichaud.com/mailman/listinfo/pmwiki-users
> 


-- 
Are you interested in using Linux?
Download Libranet 2.8.1 for free and try it out.
http://www.libranet.com/trial_download.html



More information about the pmwiki-users mailing list