[refpolicy] Unexpected user_u permission denied for httpd_user_content_t

[refpolicy] Unexpected user_u permission denied for httpd_user_content_t

[Simon Peter Nicholls]

Is it known behaviour that user_u logins get locked out of their own web 
content?

If I login as a regular default login, I get user_u:

$ id -Z
user_u:user_r:user_t

I now want to start working up some web content, so I create the regular 
top level folder:

$ mkdir public_html

And see in the message log that restorecond has relabelled it for me. 
httpd_enable_homedirs is on:

restorecond: Reset file context /home/user/public_html: 
user_u:object_r:user_home_t->user_u:object_r:httpd_user_content_t

So far so good. I'll enter that directory so I can work up some HTML:

$ cd public_html
-bash: cd: public_html: Permission denied

Oops. I can't even list the attributes of the directory without having 
sysadm_r for example.

So at this point my user is already locked out of their own content, 
which doesn't feel right to me. Policy implementation aside, the access 
granted to Apache for using these files should be in addition to 
established permissions, not instead of.

Is this a known "rough edge" with refpolicy, or is this expected to work?

It's important for my situation, thinking ahead to distributed web 
deployment, that particular logins via SSH have management access to web 
content by default, without the need to switch roles to do so.

Thanks.

[refpolicy] Unexpected user_u permission denied for httpd_user_content_t

[Dominick Grift]

On Sat, Feb 12, 2011 at 06:04:13PM +0100, Simon Peter Nicholls wrote:
> Is it known behaviour that user_u logins get locked out of their own web 
> content?
> 
> If I login as a regular default login, I get user_u:
> 
> $ id -Z
> user_u:user_r:user_t
> 
> I now want to start working up some web content, so I create the regular 
> top level folder:
> 
> $ mkdir public_html
> 
> And see in the message log that restorecond has relabelled it for me. 
> httpd_enable_homedirs is on:
> 
> restorecond: Reset file context /home/user/public_html: 
> user_u:object_r:user_home_t->user_u:object_r:httpd_user_content_t
> 
> So far so good. I'll enter that directory so I can work up some HTML:
> 
> $ cd public_html
> -bash: cd: public_html: Permission denied
> 
> Oops. I can't even list the attributes of the directory without having 
> sysadm_r for example.
> 
> So at this point my user is already locked out of their own content, 
> which doesn't feel right to me. Policy implementation aside, the access 
> granted to Apache for using these files should be in addition to 
> established permissions, not instead of.
> 
> Is this a known "rough edge" with refpolicy, or is this expected to work?
> 
> It's important for my situation, thinking ahead to distributed web 
> deployment, that particular logins via SSH have management access to web 
> content by default, without the need to switch roles to do so.

Should work in current policy. httpd_user* content is userdom_user_home_content, so that would mean users have full access


There is also an apache_role providing access to httpd_user* content. That and the above userdom_user_home_content is conflicting though (duplicate)

I would use guest_u instead if possible for your situation. It might even work here unline user_u.

To make it work for user_u, you could try:

mkdir ~/myuser; cd ~/myuser; echo "policy_module(myuser, 1.0.0) gen_require(` type user_t, role user_r; ') apache_role(user_r, user_t)" > myuser.te; make -f /usr/share/selinux/devel/Makefile myuser.pp

sudo semodule -i myuser.pp
  
But again, i would try guest_u first

> 
> Thanks.
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20110212/6aa4c6f2/attachment.bin 

[refpolicy] Unexpected user_u permission denied for httpd_user_content_t

[Dominick Grift]

On Sat, Feb 12, 2011 at 06:04:13PM +0100, Simon Peter Nicholls wrote:
> Is it known behaviour that user_u logins get locked out of their own web 
> content?
> 
> If I login as a regular default login, I get user_u:
> 
> $ id -Z
> user_u:user_r:user_t
> 
> I now want to start working up some web content, so I create the regular 
> top level folder:
> 
> $ mkdir public_html
> 
> And see in the message log that restorecond has relabelled it for me. 
> httpd_enable_homedirs is on:
> 
> restorecond: Reset file context /home/user/public_html: 
> user_u:object_r:user_home_t->user_u:object_r:httpd_user_content_t
> 
> So far so good. I'll enter that directory so I can work up some HTML:
> 
> $ cd public_html
> -bash: cd: public_html: Permission denied
> 
> Oops. I can't even list the attributes of the directory without having 
> sysadm_r for example.
> 
> So at this point my user is already locked out of their own content, 
> which doesn't feel right to me. Policy implementation aside, the access 
> granted to Apache for using these files should be in addition to 
> established permissions, not instead of.
> 
> Is this a known "rough edge" with refpolicy, or is this expected to work?
> 
> It's important for my situation, thinking ahead to distributed web 
> deployment, that particular logins via SSH have management access to web 
> content by default, without the need to switch roles to do so.
> 
> Thanks.

Whoops my previously reply only partially applies to refpolicy. I thought you were using a redhat distro.

As for refpolicy, i guess youll have to do the apache_role trick that i showed. (i would still do it for guest_t/guest_r instead of user_t/user_r though)

> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20110212/829ab59a/attachment.bin 

[refpolicy] Unexpected user_u permission denied for httpd_user_content_t

[Dominick Grift]

On Sat, Feb 12, 2011 at 06:04:13PM +0100, Simon Peter Nicholls wrote:
> Is it known behaviour that user_u logins get locked out of their own web 
> content?
> 
> If I login as a regular default login, I get user_u:
> 
> $ id -Z
> user_u:user_r:user_t
> 
> I now want to start working up some web content, so I create the regular 
> top level folder:
> 
> $ mkdir public_html
> 
> And see in the message log that restorecond has relabelled it for me. 
> httpd_enable_homedirs is on:
> 
> restorecond: Reset file context /home/user/public_html: 
> user_u:object_r:user_home_t->user_u:object_r:httpd_user_content_t
> 
> So far so good. I'll enter that directory so I can work up some HTML:
> 
> $ cd public_html
> -bash: cd: public_html: Permission denied
> 
> Oops. I can't even list the attributes of the directory without having 
> sysadm_r for example.
> 
> So at this point my user is already locked out of their own content, 
> which doesn't feel right to me. Policy implementation aside, the access 
> granted to Apache for using these files should be in addition to 
> established permissions, not instead of.
> 
> Is this a known "rough edge" with refpolicy, or is this expected to work?
> 
> It's important for my situation, thinking ahead to distributed web 
> deployment, that particular logins via SSH have management access to web 
> content by default, without the need to switch roles to do so.

Whoops my previoussly reply assumed you were using a redhat distro instead of plain refpolicy.

So you will probably have to create a loadable module with the apache_role() called, preferable for guest_t/guest_r.


> 
> Thanks.
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20110212/afbbe2ea/attachment.bin 

[refpolicy] Unexpected user_u permission denied for httpd_user_content_t

[Simon Peter Nicholls]

On 12/02/11 20:35, Dominick Grift wrote:
> Whoops my previoussly reply assumed you were using a redhat distro 
> instead of plain refpolicy.
> So you will probably have to create a loadable module with the apache_role() called, preferable for guest_t/guest_r.

I tried this just now, and it didn't work. Looking through the Apache 
interface file, it looks like apache_role gives manage access to user_ra 
and user_rw content, but only relabelling for regular old 
httpd_user_content_t. I can verify my module enforces these perms, so 
the build process seems fine, but I'd rather not give more rights than 
desired of course.

Something like "allow guest_t httpdcontent : dir_file_class_set *;" 
allows me broad access to get up and running, but I'm curious what the 
underlying issue is with Apache policy. Should it be using typeattribute 
to flag httpd_user_content_t as a user manageable file, so that regular 
'allow' rules for user account file management can automatically pick it up?