[GRLUG] permission denied: apache group

[Eric Beversluis]

On Sat, 2012-01-07 at 21:18 +0000, Nathan Phillip Brink wrote:
> 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 ;-)
> 
Yes--logging out and back in did it. 
Thanks.
> _______________________________________________
> grlug mailing list
> grlug at grlug.org
> http://shinobu.grlug.org/cgi-bin/mailman/listinfo/grlug



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.