-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 06/23/2011 05:49 PM, Dominick Grift wrote:
> On 06/23/2011 11:36 PM, Daniel B. Thurman wrote:
>
>> Almost worked! I had to add to do:
>
>
>> But I ran into a tough nut to crack, setroubleshooter was complaining:
>
>> + SELinux is preventing /usr/sbin/httpd from using potentially
>> mislabeled files last_jpeg.
>> + SELinux is preventing /usr/sbin/httpd from using potentially
>> mislabeled files event.
>
>> These files are located in: /dev/shm/kmotion_ramdisk areas, so I added:
>
>> semanage fcontext -a -t httpd_sys_content_rw_t
>> "/dev/shm/kmotion_ramdisk(/.*)?"
>> restorecon -R -v -F /dev/shm/kmotion_ramdisk/
>
>> and yet, the odd-ball here is that all the files in this directory shows
>> context as:
>
>> restorecon reset /dev/shm/kmotion_ramdisk/01/last_jpeg context
>> system_u:object_r:httpd_sys_rw_content_t:s0->system_u:object_r:device_t:s0
>
> Yes those two types are aliased buth have the same properties. i never
> understand why they did that.
>
We defined the type httpd_sys_content_rw_t originally, but upstream
wanted it changed to httpd_sys_rw_content_t, so we created an ALIAS
rather then forcing everyone to relabel.
>> restorecon reset /dev/shm/kmotion_ramdisk/events context
>> system_u:object_r:httpd_sys_rw_content_t:s0->system_u:object_r:device_t:s0
>
>> Look carefully ==> _rw_ <== is put into the wrong position!
>
>> I could test this using chcon and the results are the same.
>
>> Something is preventing me from properly labelling the files in
>> /dev/shm/kmotion_ramdisk area since _rw_ is put after 'sys'
>> instead of after 'content'!
>
>> I tried:
>
>> chcon -R -t httpd_sys_content_rw_t /dev/shm/kmotion_ramdisk (_rw_ is in
>> the wrong position)
>
>> I also tried to see if I get a different result as if _rw_ would be swapped:
>
>> chcon -R -t httpd_sys_rw_content_t /dev/shm/kmotion_ramdisk (_rw_ is
>> still in the wrong position)
>
>
>> How do I fix this?
>
> I dont see a need to fix that since those types are aliased.
>
> You have another issue here though.
>
> /dev//shm is a tmpfs meaning each time you boot it will be cleared.
>
> i do not think that httpd_t is allowed to create files in /dev/shm by
> default.
>
> So you would in that case need to allow httpd_t to create files (and
> directories) there. To do that properly you would probably need to
> create a type owned by apache, and allow apache to type transition in
> tmpfs_t directories.
>
> example:
>
> myapache.te
>
> policy_module(myapache, 1.0.0)
>
> gen_require(` type httpd_t; ')
>
> type httpd_tmpfs_t;
> files_tmpfs_file(httpd_tmpfs_t)
>
> manage_dirs_pattern(httpd_t, httpd_tmpfs_t, httpd_tmpfs_t)
> manage_files_pattern(httpd_t, httpd_tmpfs_t, httpd_tmpfs_t)
> fs_tmpfs_filetrans(httpd_t, httpd_tmpfs_t, { dir file })
>
We have this code in all Current Fedora 15 and beyond policy and RHEL6.
>
> then:
>
> make -f /usr/share/selinux/devel/Makefile myapache.pp
> sudo semodule myapache.pp
>
> service httpd stop
> rm -rf /dev/shm/kmotion_ramdisk
> service httpd start
>
> If you would implement that policy then httpd_t would be allowed to
> create dirs and files in /dev/shm and it would create them with type
> httpd_tmpfs_t automatically.
>
>> --
>> selinux mailing list
>> selinux@xxxxxxxxxxxxxxxxxxxxxxx
>> https://admin.fedoraproject.org/mailman/listinfo/selinux
>
- --
selinux mailing list
selinux@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/selinux
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk4Ehn8ACgkQrlYvE4MpobMTxwCg3sq6hm3NCIrolQczKnuunBC6
DzgAoIItGTswg/396zodQh+5haNmLY9I
=/nEu
-----END PGP SIGNATURE-----
--
selinux mailing list
selinux@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/selinux
