[Note: I sent this message yesterday without first subscribing to the list -- intending to check the web archive for responses. Because my message has not yet shown up in the web archive, I subscribed in order to re-send this. My apologies if both messages make it out of the moderation queue.]
Last summer, I set up a network with about a dozen stationary boxes and 15-20 moveable users. All users are authenticating via FreeIPA, and have their home directories NFS-mounted from a central file server. Both the desktop boxes and the file server were running Fedora 16.
+ User home directories were mounted from "/srv/exports/<user_name>".
+ The desktop boxes had SE Linux boolean "use_nfs_home_dirs=1".
+ The file server had "/etc/selinux/targeted/contexts/files/ file_contexts.local" with:
/srv system_u:object_r:home_root_t:s0
All was working well.
In March, I upgraded all of the desktop boxes, as well as the file server and the FreeIPA server to Fedora 18.
+ User home directories are still mounted from "/srv/exports/ <user_name>".
+ The desktop boxes still have SE Linux boolean "use_nfs_home_dirs=1".
+ The file server still has "/etc/selinux/targeted/contexts/files/ file_contexts.local" with:
/srv system_u:object_r:home_root_t:s0
The problems is that, as some users create files, they are being created with context:
"system_u:object_r:user_home_t:s0"
rather than:
"unconfined_u:object_r:user_home_t:s0"
If I run "restorecon -FR /srv" , then the files are re-labelled to the "unconfined_u".
I don't know how frequently files are created with the wrong context.
Any ideas as to what is happening?
Thanks.
On 04/20/2013 01:40 AM, Mike Pinkerton wrote:
[Note: I sent this message yesterday without first subscribing to the list -- intending to check the web archive for responses. Because my message has not yet shown up in the web archive, I subscribed in order to re-send this. My apologies if both messages make it out of the moderation queue.]
Last summer, I set up a network with about a dozen stationary boxes and 15-20 moveable users. All users are authenticating via FreeIPA, and have their home directories NFS-mounted from a central file server. Both the desktop boxes and the file server were running Fedora 16.
User home directories were mounted from "/srv/exports/<user_name>".
The desktop boxes had SE Linux boolean "use_nfs_home_dirs=1".
The file server had
"/etc/selinux/targeted/contexts/files/file_contexts.local" with:
/srv system_u:object_r:home_root_t:s0All was working well.
In March, I upgraded all of the desktop boxes, as well as the file server and the FreeIPA server to Fedora 18.
- User home directories are still mounted from
"/srv/exports/<user_name>".
The desktop boxes still have SE Linux boolean "use_nfs_home_dirs=1".
The file server still has
"/etc/selinux/targeted/contexts/files/file_contexts.local" with:
/srv system_u:object_r:home_root_t:s0The problems is that, as some users create files, they are being created with context:
"system_u:object_r:user_home_t:s0"rather than:
"unconfined_u:object_r:user_home_t:s0"If I run "restorecon -FR /srv" , then the files are re-labelled to the "unconfined_u".
I don't know how frequently files are created with the wrong context.
Any ideas as to what is happening?
Thanks.
Dan wrote a great blog
http://danwalsh.livejournal.com/63586.html
where you can find answers. Basically "unconfined_u" tells you that files have been created by a process running with "unconfined_u:*:*:* context.
Regards, Miroslav
On 6 May 2013, at 02:33, Miroslav Grepl wrote:
On 04/20/2013 01:40 AM, Mike Pinkerton wrote:
Last summer, I set up a network with about a dozen stationary boxes and 15-20 moveable users. All users are authenticating via FreeIPA, and have their home directories NFS-mounted from a central file server. Both the desktop boxes and the file server were running Fedora 16.
- User home directories were mounted from "/srv/exports/
<user_name>".
The desktop boxes had SE Linux boolean "use_nfs_home_dirs=1".
The file server had "/etc/selinux/targeted/contexts/files/
file_contexts.local" with:
/srv system_u:object_r:home_root_t:s0All was working well.
In March, I upgraded all of the desktop boxes, as well as the file server and the FreeIPA server to Fedora 18.
- User home directories are still mounted from "/srv/exports/
<user_name>".
- The desktop boxes still have SE Linux boolean
"use_nfs_home_dirs=1".
- The file server still has "/etc/selinux/targeted/contexts/files/
file_contexts.local" with:
/srv system_u:object_r:home_root_t:s0The problems is that, as some users create files, they are being created with context:
"system_u:object_r:user_home_t:s0"rather than:
"unconfined_u:object_r:user_home_t:s0"If I run "restorecon -FR /srv" , then the files are re-labelled to the "unconfined_u".
I don't know how frequently files are created with the wrong context.
Any ideas as to what is happening?
Thanks.
Dan wrote a great blog
http://danwalsh.livejournal.com/63586.html
where you can find answers. Basically "unconfined_u" tells you that files have been created by a process running with "unconfined_u:*:*:* context.
Miroslav, thanks for replying.
I think the "user_home_t" types are correct. Our problem is that a normal user doing a normal user thing -- albeit in a NFS mounted home directory -- is creating files that are labelled as "system_u" rather than "unconfined_u", which then limits the user's subsequent ability to interact with the file. If this problem existed prior to our upgrade to F18, we did not notice it.
From your response, I take it that some normal user processes are running in the wrong context, resulting in files being created with a "system_u" context. Any thoughts on how to track down which processes are running in the wrong context, and how to fix that?
Thanks.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 05/06/2013 03:02 PM, Mike Pinkerton wrote:
On 6 May 2013, at 02:33, Miroslav Grepl wrote:
On 04/20/2013 01:40 AM, Mike Pinkerton wrote:
Last summer, I set up a network with about a dozen stationary boxes and 15-20 moveable users. All users are authenticating via FreeIPA, and have their home directories NFS-mounted from a central file server. Both the desktop boxes and the file server were running Fedora 16.
User home directories were mounted from "/srv/exports/<user_name>".
The desktop boxes had SE Linux boolean "use_nfs_home_dirs=1".
The file server had
"/etc/selinux/targeted/contexts/files/file_contexts.local" with:
/srv system_u:object_r:home_root_t:s0
All was working well.
In March, I upgraded all of the desktop boxes, as well as the file server and the FreeIPA server to Fedora 18.
- User home directories are still mounted from
"/srv/exports/<user_name>".
- The desktop boxes still have SE Linux boolean
"use_nfs_home_dirs=1".
- The file server still has
"/etc/selinux/targeted/contexts/files/file_contexts.local" with:
/srv system_u:object_r:home_root_t:s0
The problems is that, as some users create files, they are being created with context:
"system_u:object_r:user_home_t:s0"
rather than:
"unconfined_u:object_r:user_home_t:s0"
If I run "restorecon -FR /srv" , then the files are re-labelled to the "unconfined_u".
I don't know how frequently files are created with the wrong context.
Any ideas as to what is happening?
Thanks.
Dan wrote a great blog
http://danwalsh.livejournal.com/63586.html
where you can find answers. Basically "unconfined_u" tells you that files have been created by a process running with "unconfined_u:*:*:* context.
Miroslav, thanks for replying.
I think the "user_home_t" types are correct. Our problem is that a normal user doing a normal user thing -- albeit in a NFS mounted home directory -- is creating files that are labelled as "system_u" rather than "unconfined_u", which then limits the user's subsequent ability to interact with the file. If this problem existed prior to our upgrade to F18, we did not notice it.
From your response, I take it that some normal user processes are running in the wrong context, resulting in files being created with a "system_u" context. Any thoughts on how to track down which processes are running in the wrong context, and how to fix that?
Thanks.
SELinux does not enforce on User component in any policy we ship so this is not a problem, but you do point out an inconsistency.
We should bring this up for discussion on the mail list, but I guess until we get labeling NFS we can not do anything about it. The server does not know what the label of the client process is running with.
On 6 May 2013, at 15:25, Daniel J Walsh wrote:
On 05/06/2013 03:02 PM, Mike Pinkerton wrote:
On 6 May 2013, at 02:33, Miroslav Grepl wrote:
On 04/20/2013 01:40 AM, Mike Pinkerton wrote:
Last summer, I set up a network with about a dozen stationary boxes and 15-20 moveable users. All users are authenticating via FreeIPA, and have their home directories NFS-mounted from a central file server. Both the desktop boxes and the file server were running Fedora 16.
- User home directories were mounted from "/srv/exports/
<user_name>".
The desktop boxes had SE Linux boolean "use_nfs_home_dirs=1".
The file server had
"/etc/selinux/targeted/contexts/files/file_contexts.local" with:
/srv system_u:object_r:home_root_t:s0
All was working well.
In March, I upgraded all of the desktop boxes, as well as the file server and the FreeIPA server to Fedora 18.
- User home directories are still mounted from
"/srv/exports/<user_name>".
- The desktop boxes still have SE Linux boolean
"use_nfs_home_dirs=1".
- The file server still has
"/etc/selinux/targeted/contexts/files/file_contexts.local" with:
/srv system_u:object_r:home_root_t:s0
The problems is that, as some users create files, they are being created with context:
"system_u:object_r:user_home_t:s0"
rather than:
"unconfined_u:object_r:user_home_t:s0"
If I run "restorecon -FR /srv" , then the files are re-labelled to the "unconfined_u".
I don't know how frequently files are created with the wrong context.
Any ideas as to what is happening?
Thanks.
Dan wrote a great blog
http://danwalsh.livejournal.com/63586.html
where you can find answers. Basically "unconfined_u" tells you that files have been created by a process running with "unconfined_u:*:*:* context.
Miroslav, thanks for replying.
I think the "user_home_t" types are correct. Our problem is that a normal user doing a normal user thing -- albeit in a NFS mounted home directory -- is creating files that are labelled as "system_u" rather than "unconfined_u", which then limits the user's subsequent ability to interact with the file. If this problem existed prior to our upgrade to F18, we did not notice it.
From your response, I take it that some normal user processes are running in the wrong context, resulting in files being created with a "system_u" context. Any thoughts on how to track down which processes are running in the wrong context, and how to fix that?
Thanks.
SELinux does not enforce on User component in any policy we ship so this is not a problem, but you do point out an inconsistency.
Dan, it must have created at least a wrinkle, because I did not notice the labelling problem until a user complained about not being able to use one of her files. Running "restorecon -FR /srv" fixed the problem for her.
We should bring this up for discussion on the mail list, but I guess until we get labeling NFS we can not do anything about it. The server does not know what the label of the client process is running with.
The server does the right thing some of the time. In the same home directory, I'll see some files with "unconfined_u" and others with "system_u".
I suppose until y'all figure this out, I'll set up a cron job to run "restorecon -FR /srv" on the file server every night.
Thanks.
On 05/06/2013 10:57 PM, Mike Pinkerton wrote:
On 6 May 2013, at 15:25, Daniel J Walsh wrote:
On 05/06/2013 03:02 PM, Mike Pinkerton wrote:
On 6 May 2013, at 02:33, Miroslav Grepl wrote:
On 04/20/2013 01:40 AM, Mike Pinkerton wrote:
Last summer, I set up a network with about a dozen stationary boxes and 15-20 moveable users. All users are authenticating via FreeIPA, and have their home directories NFS-mounted from a central file server. [...]The problems is that, as some users create files, they are being created with context:
"system_u:object_r:user_home_t:s0"
rather than:
"unconfined_u:object_r:user_home_t:s0"
If I run "restorecon -FR /srv" , then the files are re-labelled to the "unconfined_u".
I don't know how frequently files are created with the wrong context.
Any ideas as to what is happening?
Thanks.
Dan wrote a great blog
http://danwalsh.livejournal.com/63586.html
where you can find answers. Basically "unconfined_u" tells you that files have been created by a process running with "unconfined_u:*:*:* context.
[...]
SELinux does not enforce on User component in any policy we ship so this is not a problem, but you do point out an inconsistency.
Dan, it must have created at least a wrinkle, because I did not notice the labelling problem until a user complained about not being able to use one of her files. Running "restorecon -FR /srv" fixed the problem for her.
We should bring this up for discussion on the mail list, but I guess until we get labeling NFS we can not do anything about it. The server does not know what the label of the client process is running with.
The server does the right thing some of the time. In the same home directory, I'll see some files with "unconfined_u" and others with "system_u".
I suppose until y'all figure this out, I'll set up a cron job to run "restorecon -FR /srv" on the file server every night.
As an alternative workaround you could rely on inotify to trigger a relabel each time a file is created
Restorecond perhaps can help here
best
2013/5/6, Manuel Wolfshant wolfy@nobugconsulting.ro:
On 05/06/2013 10:57 PM, Mike Pinkerton wrote:
On 6 May 2013, at 15:25, Daniel J Walsh wrote:
On 05/06/2013 03:02 PM, Mike Pinkerton wrote:
On 6 May 2013, at 02:33, Miroslav Grepl wrote:
On 04/20/2013 01:40 AM, Mike Pinkerton wrote:
Last summer, I set up a network with about a dozen stationary boxes and 15-20 moveable users. All users are authenticating via FreeIPA, and have their home directories NFS-mounted from a central file server. [...]The problems is that, as some users create files, they are being created with context:
"system_u:object_r:user_home_t:s0"
rather than:
"unconfined_u:object_r:user_home_t:s0"
If I run "restorecon -FR /srv" , then the files are re-labelled to the "unconfined_u".
I don't know how frequently files are created with the wrong context.
Any ideas as to what is happening?
Thanks.
Dan wrote a great blog
http://danwalsh.livejournal.com/63586.html
where you can find answers. Basically "unconfined_u" tells you that files have been created by a process running with "unconfined_u:*:*:* context.
[...]
SELinux does not enforce on User component in any policy we ship so this is not a problem, but you do point out an inconsistency.
Dan, it must have created at least a wrinkle, because I did not notice the labelling problem until a user complained about not being able to use one of her files. Running "restorecon -FR /srv" fixed the problem for her.
We should bring this up for discussion on the mail list, but I guess until we get labeling NFS we can not do anything about it. The server does not know what the label of the client process is running with.
The server does the right thing some of the time. In the same home directory, I'll see some files with "unconfined_u" and others with "system_u".
I suppose until y'all figure this out, I'll set up a cron job to run "restorecon -FR /srv" on the file server every night.
As an alternative workaround you could rely on inotify to trigger a relabel each time a file is created -- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
On 7 May 2013, at 02:04, yersinia wrote:
Restorecond perhaps can help here
best
2013/5/6, Manuel Wolfshant wolfy@nobugconsulting.ro:
On 05/06/2013 10:57 PM, Mike Pinkerton wrote:
On 6 May 2013, at 15:25, Daniel J Walsh wrote:
We should bring this up for discussion on the mail list, but I guess until we get labeling NFS we can not do anything about it. The server does not know what the label of the client process is running with.
The server does the right thing some of the time. In the same home directory, I'll see some files with "unconfined_u" and others with "system_u".
I suppose until y'all figure this out, I'll set up a cron job to run "restorecon -FR /srv" on the file server every night.
As an alternative workaround you could rely on inotify to trigger a relabel each time a file is created
My understanding is that inotify is not itself recursive, although "inotifywait -r" will recursively create inotify watches on up to 8192 subdirectories.
My NFS-mounted home directories are in a tree with over 2,400 subdirectories. So inotifywait should work but will probably take considerable resources.
From the man page, I assume that restorecond will use inotify to watch files listed in /etc/selinux/restorecond.conf. Is restorecond recursive like inotifywait? Will adding "/srv/exports/*" to restorecond.conf cause restorecond to recursively watch all 2,400+ subdirectories?
Thanks for all the great workaround ideas.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 05/07/2013 10:21 AM, Mike Pinkerton wrote:
On 7 May 2013, at 02:04, yersinia wrote:
Restorecond perhaps can help here
best
2013/5/6, Manuel Wolfshant wolfy@nobugconsulting.ro:
On 05/06/2013 10:57 PM, Mike Pinkerton wrote:
On 6 May 2013, at 15:25, Daniel J Walsh wrote:
We should bring this up for discussion on the mail list, but I guess until we get labeling NFS we can not do anything about it. The server does not know what the label of the client process is running with.
The server does the right thing some of the time. In the same home directory, I'll see some files with "unconfined_u" and others with "system_u".
I suppose until y'all figure this out, I'll set up a cron job to run "restorecon -FR /srv" on the file server every night.
As an alternative workaround you could rely on inotify to trigger a relabel each time a file is created
My understanding is that inotify is not itself recursive, although "inotifywait -r" will recursively create inotify watches on up to 8192 subdirectories.
My NFS-mounted home directories are in a tree with over 2,400 subdirectories. So inotifywait should work but will probably take considerable resources.
From the man page, I assume that restorecond will use inotify to watch files listed in /etc/selinux/restorecond.conf. Is restorecond recursive like inotifywait? Will adding "/srv/exports/*" to restorecond.conf cause restorecond to recursively watch all 2,400+ subdirectories?
Thanks for all the great workaround ideas.
No restorecond will not do this. It is not recursive, and I think you would have considerable problems with it as far as resources. Best to run restorecon periodically. But again from an SELinux point of view there is no difference between system_u and unconfined_u, no policy that Fedora ships cares about the SELinux User componant on files on disk.
selinux@lists.fedoraproject.org
-
Daniel J Walsh -
Manuel Wolfshant -
Mike Pinkerton -
Miroslav Grepl -
yersinia