I assume you're running the strict policy here; in the future please
state explicitly what Fedora release and policy you're using.
On Sat, 2005-03-12 at 18:46 -0600, Christofer C. Bell wrote:
> However, this context is not inherited when creating a public_html
> directory as a user or as root in a user home directory. In
> otherwords, when creating a public_html directory, this is what you
> get:
>
> drwxrwxr-x cbell cbell user_u:object_r:user_home_t public_html
Security contexts are not typically assigned based on filenames after
system initialization. In other words, if you use 'mkdir', the GNOME
file manager, or whatever to create a file, it will have a context
assigned to it based solely on the security context of its parent
directory.
You can however later use a command such as "restorecon" to change the
security context of a file based on its name. Or you can use "chcon" to
assign contexts directly regardless of file name.
> (I must admit some confusion about the initial user_u user context
> since this is not defined in file_contexts).
It's debatable whether it should be system_u or user_u; the user
identity component of the security context has a few purposes. One is
to identify the creator of an object. If the system created it, then
logically the user is system_u. But it's also used in the constraints,
for example to ensure a process can't relabel a file with a differing
user identity. If you want to allow a user that privilege, the user
identity needs to be user_u.
Probably by default all files in the user's home directory should be
user_u (or staff_u).
> At anyrate, the user label is correctly set to system_u, the role is
> unchanged with object_r, and the type is changed to
> http_user_content_t. This is the context I'd like public_html
> directories to automatically assume when created. Is this possible?
>
Not really. An explicit decision was made to not assign contexts based
on filenames after system initialization inside the kernel ("mkdir",
"open", etc). Instead, one should modify the system to assign them
correctly. In this case we probably should have public_html
in /etc/skel as Ivan suggested. Or something similar.
> Further puzzles:
>
> When creating files in this public_html directory (after resetting the
> directory to the correct context) yields more puzzling results:
>
> [cbell@circe public_html]$ touch test
> [cbell@circe public_html]$ ls -Z
> -rw-rw-r-- cbell cbell user_u:object_r:httpd_sys_content_t test
Right; if the directory has type httpd_sys_content_t, any files created
inside it will inherit that type.
> Note that in this case, the file has been set to user context user_u,
> role object_r, and type httpd_sys_content_t. This is the type that's
> supposedly reserved for the machine's public web directories:
Indeed.
> o How can one cause the correct httpd_user_content_t type to be
> automatically assigned to user public_html directories (and
> subdirectories)?
This sounds like a recent bug introduced in the strict policy.
> o How can one cause the correct httpd_user_content_t type to be
> automatically assigned to user content (files) in user public_html
> directores?
That will happen automatically when the directory has that type.
> o Why are files initially receiving a user context of user_u rather
> than system_u ?
When they're created after system initalization? Because the user
identity is derived from the identity of the creating process.
> o When I installed this server and restored user data to it, the user
> context on all the files was set to root rather than user_u (and why
> not system_u?). I've reset everything to the correct user context
> with chcon, but I'd like to know why this happened.
Presumably you untarred (or whatever) the data as root:sysadm_r? In
that case the files again by default inherit the user identity of the
creating process. For restoring data, you should use a tool that
preserves security contexts.
http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/rhlcommon-chapter-0017.html#RHLCOMMON-SECTION-0067
Also rsync in rawhide has a -X option.
