[GRLUG] permission denied: apache group

[Nathan Phillip Brink]

On Sat, Jan 07, 2012 at 03:53:35PM -0500, Adam Tauno Williams wrote:
> On Sat, 2012-01-07 at 15:42 -0500, Eric Beversluis wrote:
> > On Sat, 2012-01-07 at 15:25 -0500, Adam Tauno Williams wrote:
> > > On Sat, 2012-01-07 at 15:18 -0500, Eric Beversluis wrote:
> > > > I've got my WordPress files on localhost owned by apache (seemed to be
> > > > the only way I could get WP to do automatic updates). Permissions set to
> > > > 775.
> > > > I've made myself a member of the apache group (confirmed that). But I
> > > > get 'permission denied' when I try to create a new subdirectory in a WP
> > > > directory (both from command line and from Nautilus).
> > > > Is there something about apache that's blocking this? Or am I missing
> > > > something else?
> > Not having trouble with permissions etc in general.
> > > Do you have anything like SELinux or AppArmour enabled?
> > SELinux disabled, as far as I know.
> > > Do you have nscd running on the box?  [did you restart nscd after the
> > > change of group membership]
> > > I think not. When I tried nscd -help I was prompted if I wanted to install it.
> > > If you run "id" in that session/terminal do you see yourself as a member
> > > of the group?
> > > id => "uid=500(eric) gid=500(eric) groups=500(eric)"
> 
> Then it won't work; since you aren't yet a member.

No. id looks at the user's current login session.

> Do a "service nscd restart", see if it shows up then.  NSCD [the
> name-service-cache-daemon] cache's lookups into NSS [which
> includes /etc/group, /etc/passwd amoung others].  So sometimes changes
> are not apparently immediately as you get the cached response.
> Generally nscd is a deal-with-the-devil IMO and unless you are using a
> network naming service [NIS/LDAP/etc...] or have a large /etc/passwd
> file - disable it.

Correct. But, as I said in my previous email, this issue can only come
up if:

1. A lookup of the apache group (such as by running `getent group
   apache') has caused the apache group to be in nscd's cache
   recently. Such lookups do not occur that often: they do occur when
   the user logs in and his login session is set up, but not randomly
   under normal system use (unless if nautilus or `ls -l' is perhaps
   looking at a directory of files owned by the apache group). nscd's
   cache life is short enough and the occurance of lookups of the
   apache group sparse enough for this to be uncommon.

2. The user has to reestablish his login session before the apache
   group's entry in NSCD's cache is dropped. Since the user was added
   to the apache group at least half an hour ago, this cannot be the
   case unless if NSCD is running with insane and non-default
   settings.

Secondly, the kernel and id are looking at the groups registered with
the user's current login session, not with the groups that would be
applied to the user if he were to log in again. To get this latter
effect, run `id $(whoami)' which should include apache. This is asking
id to display the groups which would be applied to a user if he were
to establish a new login session, so you must re-login to act as
members of these groups.

The lookups which are performed by `id $(whoami)' are only done once
per a user's login session: when the user first logs in, the `login'
program looks up all of the groups to determine which ones the newly
logged-in user belongs to. It then applies these groups to its
processes before setting the UID to the user's UID. This way, the NSS
lookups are done once and in the userspace and the effects of the
group memberships last as long as that login session survives.

> Otherwise membership for the effective user of a process [your bash or
> gnome-terminal whatever] is inherited from its parent.  So logging off
> and back on might be necessary if you can't get identity to reload any
> other way.

Hmm... I think I said something to that effect ;-)

-- 
binki

Look out for missing or extraneous apostrophes!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://shinobu.grlug.org/pipermail/grlug/attachments/20120107/0ec53e74/attachment-0001.pgp>