There is nothing more frustrating than not having permissions set correctly on a server. I recently tried to commit a bunch of files to subversion and received the following error:

svn: Can't create directory 'sites/default/files/some/path/.svn': Permission denied

This usually indicates your user does not have permission to alter the .svn folders to execute the subversion commit command. The failed command will leave your subversion status with a tilde (~):

$ svn stat
~      sites/default/files/some/path
~      sites/default/files/some/other/path

You'll first need to reset permissions and ownership:

# change directories, you don't want to reset every file permission
$ cd sites/default/files

# use a find command and "-exec" switch to reset ownership and permissions
# NOTE: the group, owner, and permissions will vary on every server configuration
$ find . -exec chown Eric.apache {} \; -exec chmod -R ug+rw {} \;

Now, you can revert the files to remove the tilde (~) status:

$ svn stat
~      sites/default/files/some/path
~      sites/default/files/some/other/path
$ svn revert "sites/default/files/some/path"
$ svn revert "sites/default/files/some/other/path"
$ svn stat
?      sites/default/files/some/path
?      sites/default/files/some/other/path

At this point, you should be able to re-add the files to subversion and commit.

Recently, I was working with the file_get_contents() and file_put_contents() functions to read in a file, change its contents, and write it to the file system. Although the is_writable() function returned TRUE, my file_put_contents() command was returning FALSE. This lead me to try a fopen command with the "w" switch (which opens a file for writing and truncates it), and still no luck. Although the file had group permissions to read and write on the file system, the file was owned by a non-apache user. In certain PHP configurations (safe mode, etc) this will not work.

I then created a hook_requirements() function to test for the proper file permissions for my custom module. When I deployed my code to the test server, I got a white screen, which usually signifies a PHP fatal error. Upon review of the apache vhost error log, I saw the function I used "posix_getpwuid" was not defined.

In the end I decided to create a helper function that returns the owner of a file:

<?php
function _MYMODULE_get_file_owner($file) {
    
  // if posix library is installed:
  if (function_exists('posix_getpwuid')) {
    $owner = fileowner($file);
    $ownerInfo = posix_getpwuid($owner);
    if ($ownerInfo['name']) return $ownerInfo['name']; 
  }

  // try using ls & awk
  $command = "ls -l $file | awk '{print $3}'";
  $result = exec($command);
  if ($result) return $result;
    
  return false;

}
?>

NOTE: the "stat" shell function could also be used:

<?php
$command = "stat -c %U $file";
?>

I've been working on an intranet site that needed to have typical intranet permissions: unauthenticated users can see a handful of pages and the rest of the nodes are only visible to authenticated users. Instead of having the user specify permissions for every page, I figured it would be more usable to have them specify a list of pages available to unauth users.

I created an admin settings page callback to generate the form with a single textarea input. Users will enter a list of URLs in the textarea, one per line:

<?php
function MYMODULE_menu() {
  $items = array();

  $items['admin/settings/MYMODULE'] = array(
    'title' => 'MYMODULE Settings',
    'page callback' => 'drupal_get_form',
    'page arguments' => array('_MYMODULE_callback_admin_settings'),
    'type' => MENU_NORMAL_ITEM,
    'access arguments' => array('administer site configuration'),
  );

  return $items;
}

function _MYMODULE_callback_admin_settings() {
  $form = array();

  $form['MYMODULE_unauth_pages'] = array(
    '#type' => 'textarea',
    '#title' => 'Unauth Pages',
    '#default_value' => variable_get('MYMODULE_unauth_pages',''),
  );
    
  return system_settings_form($form);
}
?>

For this example, I entered the following URLs in the textarea:

<front>
about-us
contact-us

I then added a menu_alter hook function to override the access control for viewing nodes:

<?php
function MYMODULE_menu_alter(&$items) {
  // per unauth pages, replace the callback function
  if (function_exists('_MYMODULE_node_access')) {
    // note: access callback function was previously: node_access
    $items['node/%node']['access callback'] = '_MYMODULE_node_access';
  }
}
?>

And, then added a new access control function:

<?php
function _MYMODULE_node_access($op, $node) {

  // check if user is unauth
  if (in_array('anonymous user', array_values($GLOBALS['user']->roles))) {

    // get a list of unauth pages
    $unauth = variable_get('MYMODULE_unauth_pages','');
    $unauth = explode("\r\n", trim($unauth));
        
    // replace <front> with empty string
    if (in_array('<front>', $unauth)) {
      $unauth[array_search('<front>',$unauth)] = '';
    }
        
    // check for unauth entries
    if (is_array($unauth) && count($unauth)) {
      // check if current url is allowed
      if (!in_array($_REQUEST['q'], $unauth)) {
        return false;
      }            
    }
  }
    
  // default to node_access function result
  return node_access($op, $node);
    
}
?>

Now, unauth users have access ONLY to the pages you define and the rest of the node viewing permissions default to the node_access function.

In a recent Drupal implementation, we used the Organic Groups module to allow users in a certain role to add content to group nodes. On the content type edit screens, for "Organic groups usage", we chose "Standard group post (typically only author may edit)". Unfortunately, this text is a little deceiving. The OG module grants group administrators the ability to edit any node in the group, which was undesired for our situation.

In the og.module module file, the function og_menu_alter() overrides the normal access control of a user's ability to edit nodes:

<?php
function og_menu_alter(&$menu) {
  // If og_access is disabled, we at least add back the edit tab for group admins to edit their posts.
  $menu['node/%node/edit']['access callback'] = 'og_menu_access_node_edit';
  $menu['node/%node/edit']['access arguments'] = array(1);
}
?>

Prior to og_menu_alter() being executed, the menu structure was:

[access callback] => node_access
[access arguments] => Array
    (
        [0] => update
        [1] => 1
    )

The above array structure relies on the node_access() function to determine if a user has permission to edit a node. One solution to this problem is to define code in a module to reset this menu structure:

<?php
function MYMODULE_menu_alter(&$menu) {
  $menu['node/%node/edit']['access callback'] = 'node_access';
  $menu['node/%node/edit']['access arguments'] = array('update',1);
}
?>

Now, group administrators no longer have permission to edit every content item in a group.

Here's a quick script to reset ownership on a directory and then commit all changes (deletions, additions, and modifications) to subversion...

#!/bin/sh

_DIR="/path/to/my/svn/directory"
_DATE=`date +%Y\-%m\-%d\ %H\:%I\:%S`

_USER="Eric"
_GROUP="Eric"

# reset file ownership
find ${_DIR} -exec chown ${_USER}.${_GROUP} {} \;

# add new files
svn stat ${_DIR} | grep ^? | sed 's/^?      /svn add "/' | sed 's/$/"/' | sh

# remove deleted files
svn stat ${_DIR} | grep ^! | sed 's/^!      /svn del "/' | sed 's/$/"/' | sh

# commit modifications
svn commit ${_DIR} -m "Automated Commit: ${_DATE}"