I'm stumped.
I run a Java app called Solr, which does search indexing. My solr server creates the index, then I have a bunch of solr clients that rsync that index over.
The rsync itself is fine, that works. The problem is it won't write to the appropriate logfile, which is: /opt/solr/logs/rsyncd.log
/opt/solr/logs is a symlink to /var/log/store.
Here's how it looks:
==
[root@solr:~]# ls -l /opt/solr/ lrwxrwxrwx 1 tomcat tomcat 14 Apr 29 13:52 logs -> /var/log/store
[root@solr:~]# ls -ldZ /opt/solr/logs/ drwxr-xr-x tomcat tomcat user_u:object_r:var_log_t /opt/solr/logs/
[root@solr:~]# ls -ldZ /var/log/store drwxr-xr-x tomcat tomcat user_u:object_r:var_log_t /var/log/store
[root@solr:~]# ls -Z /opt/solr/logs/rsyncd.log -rw-rw-rw- tomcat tomcat user_u:object_r:var_log_t /var/log/store/rsyncd.log
==
Note that the mode is 666 on the rsyncd.log. When a client tries to connect, though, I get, in /var/log/messages:
Jun 24 10:15:02 solr rsyncd[19355]: rsync: failed to open log-file /opt/solr/logs/rsyncd.log: Permission denied (13)
But there are no avc denials (no, I don't have audit package installed, so all avc messages go to /var/log/messages -- I do get avc denials for other things).
So, at first, I didn't think it was selinux-related, and tried to troubleshoot general unix permissions. But got nowhere.
Then I noticed... when I put selinux in permissive mode, it works -- rsyncd properly logs to the above file. When I set it back to enforcing, I get the above error in /var/log/messages and nothing in the rsyncd.log, but no avc denials either.
Any ideas?
If it helps, here's how my rsyncd module looks like: ==
module solrrsync 1.0;
require { type initrc_tmp_t; type port_t; type var_log_t; type restorecon_t; type rsync_t; type usr_t; class netlink_route_socket { read create bind getattr write nlmsg_read }; class lnk_file read; class file { read write getattr create append }; class tcp_socket { name_connect name_bind }; class dir { write add_name }; }
#============= restorecon_t ============== allow restorecon_t initrc_tmp_t:file { read write }; allow restorecon_t usr_t:lnk_file read; allow restorecon_t var_log_t:lnk_file read;
#============= rsync_t ============== allow rsync_t initrc_tmp_t:file { read write }; allow rsync_t port_t:tcp_socket { name_connect name_bind }; allow rsync_t self:netlink_route_socket { read create bind getattr write nlmsg_read }; allow rsync_t usr_t:lnk_file read; allow rsync_t usr_t:file { read getattr }; allow rsync_t var_log_t:lnk_file read; allow rsync_t var_log_t:dir { write add_name }; allow rsync_t var_log_t:file { read write getattr create append };
Johnny Tan wrote:
I'm stumped.
I run a Java app called Solr, which does search indexing. My solr server creates the index, then I have a bunch of solr clients that rsync that index over.
The rsync itself is fine, that works. The problem is it won't write to the appropriate logfile, which is: /opt/solr/logs/rsyncd.log
/opt/solr/logs is a symlink to /var/log/store.
Here's how it looks:
==
[root@solr:~]# ls -l /opt/solr/ lrwxrwxrwx 1 tomcat tomcat 14 Apr 29 13:52 logs -> /var/log/store
[root@solr:~]# ls -ldZ /opt/solr/logs/ drwxr-xr-x tomcat tomcat user_u:object_r:var_log_t /opt/solr/logs/
[root@solr:~]# ls -ldZ /var/log/store drwxr-xr-x tomcat tomcat user_u:object_r:var_log_t /var/log/store
[root@solr:~]# ls -Z /opt/solr/logs/rsyncd.log -rw-rw-rw- tomcat tomcat user_u:object_r:var_log_t /var/log/store/rsyncd.log
==
Note that the mode is 666 on the rsyncd.log. When a client tries to connect, though, I get, in /var/log/messages:
Jun 24 10:15:02 solr rsyncd[19355]: rsync: failed to open log-file /opt/solr/logs/rsyncd.log: Permission denied (13)
But there are no avc denials (no, I don't have audit package installed, so all avc messages go to /var/log/messages -- I do get avc denials for other things).
So, at first, I didn't think it was selinux-related, and tried to troubleshoot general unix permissions. But got nowhere.
Then I noticed... when I put selinux in permissive mode, it works -- rsyncd properly logs to the above file. When I set it back to enforcing, I get the above error in /var/log/messages and nothing in the rsyncd.log, but no avc denials either.
Any ideas?
Turn off the dontaudit rules: # semodule -DB
You should then see the AVCs and be able to generate the policy module you need.
You can then turn back on the dontaduit rules: # semodule -B
Paul.
Paul Howarth wrote:
Turn off the dontaudit rules: # semodule -DB
You should then see the AVCs and be able to generate the policy module you need.
You can then turn back on the dontaduit rules: # semodule -B
I don't have dontaudit turned on to begin with. As I mentioned, I *do* see AVCs for other selinux problems.
For this particular problem, I do *not* see AVCs. However, when I set selinux to Permissive, it works. So I think it's selinux-related, but there are not AVCs to give me clues.
johnn
Johnny Tan wrote:
Paul Howarth wrote:
Turn off the dontaudit rules: # semodule -DB
You should then see the AVCs and be able to generate the policy module you need.
You can then turn back on the dontaduit rules: # semodule -B
I don't have dontaudit turned on to begin with. As I mentioned, I *do* see AVCs for other selinux problems.
I think you're misunderstanding what dontaudit does. There are specific policy rules which have a dontaudit flag associated with them which says even if you are auditing don't log this particular denial. What has been suggested is you disable those donaudit flags so you see ALL the denials, not just those which do not currently have the dontaudit flag set on them, which is your current situation.
John Dennis wrote:
Johnny Tan wrote:
Paul Howarth wrote:
Turn off the dontaudit rules: # semodule -DB
You should then see the AVCs and be able to generate the policy module you need.
You can then turn back on the dontaduit rules: # semodule -B
I don't have dontaudit turned on to begin with. As I mentioned, I *do* see AVCs for other selinux problems.
I think you're misunderstanding what dontaudit does. There are specific policy rules which have a dontaudit flag associated with them which says even if you are auditing don't log this particular denial.
Ok, got it. Is there a similar option for older (i.e., RHEL-5) versions? policycoreutils-1.33.12-12.el5
johnn
On Tue, 2008-06-24 at 12:39 -0400, Johnny Tan wrote:
John Dennis wrote:
Johnny Tan wrote:
Paul Howarth wrote:
Turn off the dontaudit rules: # semodule -DB
You should then see the AVCs and be able to generate the policy module you need.
You can then turn back on the dontaduit rules: # semodule -B
I don't have dontaudit turned on to begin with. As I mentioned, I *do* see AVCs for other selinux problems.
I think you're misunderstanding what dontaudit does. There are specific policy rules which have a dontaudit flag associated with them which says even if you are auditing don't log this particular denial.
Ok, got it. Is there a similar option for older (i.e., RHEL-5) versions? policycoreutils-1.33.12-12.el5
Not unless RH back-ported the support. But in older releases, you could instead install an enableaudit.pp file, e.g. semodule -b /usr/share/selinux/targeted/enableaudit.pp <exercise system to generate AVC messages> semodule -b /usr/share/selinux/targeted/base.pp
However that only dealt with dontaudit rules in the base module.
Johnny Tan wrote:
I'm stumped.
I run a Java app called Solr, which does search indexing. My solr server creates the index, then I have a bunch of solr clients that rsync that index over.
The rsync itself is fine, that works. The problem is it won't write to the appropriate logfile, which is: /opt/solr/logs/rsyncd.log
/opt/solr/logs is a symlink to /var/log/store.
A little bit more information that might help solve this...
If I remove the symlink, and /opt/solr/bin/rsyncd-start runs (which basically starts rsyncd), then rsyncd can write to /opt/solr/logs/rsyncd.log with no problems.
If I put the symlink back in (to /var/log/store), then it fails (again, with no AVC messages).
The only difference I can see between /opt/solr/logs (as a directory) and /var/log/store is the default contexts, for /opt/solr/logs, it's root:object_r:usr_t, for /var/log/store it's root:object_r:var_log_t
When I put the symlink back, I tried changing the context of /var/log/store to root:object_r:usr_t to match /opt/solr/logs, but that doesn't seem to make a difference.
Max, a list member, suggested offline that it might have to do with type_transition, which does seem to make sense.
I tried both: type_transition rsync_t var_log_t : file rsync_log_t; and type_transition rsync_t var_log_t : file usr_t;
But neither worked (I have all the appropriate allows for those contexts).
Am I going down the right path here (type_transition)? Or does anyone else have a suggestion in terms of how the symlink can be used?
johnn
On Mon, 07 Jul 2008 13:01:55 -0400 Johnny Tan linuxweb@gmail.com wrote:
Johnny Tan wrote:
I'm stumped.
I run a Java app called Solr, which does search indexing. My solr server creates the index, then I have a bunch of solr clients that rsync that index over.
The rsync itself is fine, that works. The problem is it won't write to the appropriate logfile, which is: /opt/solr/logs/rsyncd.log
/opt/solr/logs is a symlink to /var/log/store.
A little bit more information that might help solve this...
If I remove the symlink, and /opt/solr/bin/rsyncd-start runs (which basically starts rsyncd), then rsyncd can write to /opt/solr/logs/rsyncd.log with no problems.
If I put the symlink back in (to /var/log/store), then it fails (again, with no AVC messages).
The only difference I can see between /opt/solr/logs (as a directory) and /var/log/store is the default contexts, for /opt/solr/logs, it's root:object_r:usr_t, for /var/log/store it's root:object_r:var_log_t
When I put the symlink back, I tried changing the context of /var/log/store to root:object_r:usr_t to match /opt/solr/logs, but that doesn't seem to make a difference.
Max, a list member, suggested offline that it might have to do with type_transition, which does seem to make sense.
I tried both: type_transition rsync_t var_log_t : file rsync_log_t; and type_transition rsync_t var_log_t : file usr_t;
But neither worked (I have all the appropriate allows for those contexts).
Am I going down the right path here (type_transition)? Or does anyone else have a suggestion in terms of how the symlink can be used?
Can you try this policy module:
:::::::::::::: solr.fc :::::::::::::: /var/log/store(/.*)? gen_context(system_u:object_r:rsync_log_t,s0)
:::::::::::::: solr.te :::::::::::::: policy_module(solr, 0.0.1)
# ====================================================== # Declarations # ======================================================
require { type rsync_t; type rsync_log_t; }
# ====================================================== # Solr local policy # ======================================================
logging_log_file(rsync_log_t) logging_log_filetrans(rsync_t,rsync_log_t, { file dir } )
Followed by: # restorecon -rv /var/log/store
See if that helps.
Paul.
On Mon, 07 Jul 2008 13:01:55 -0400 Johnny Tan linuxweb@gmail.com wrote:
Johnny Tan wrote:
I'm stumped.
I run a Java app called Solr, which does search indexing. My solr server creates the index, then I have a bunch of solr clients that rsync that index over.
The rsync itself is fine, that works. The problem is it won't write to the appropriate logfile, which is: /opt/solr/logs/rsyncd.log
/opt/solr/logs is a symlink to /var/log/store.
A little bit more information that might help solve this...
If I remove the symlink, and /opt/solr/bin/rsyncd-start runs (which basically starts rsyncd), then rsyncd can write to /opt/solr/logs/rsyncd.log with no problems.
If I put the symlink back in (to /var/log/store), then it fails (again, with no AVC messages).
The only difference I can see between /opt/solr/logs (as a directory) and /var/log/store is the default contexts, for /opt/solr/logs, it's root:object_r:usr_t, for /var/log/store it's root:object_r:var_log_t
When I put the symlink back, I tried changing the context of /var/log/store to root:object_r:usr_t to match /opt/solr/logs, but that doesn't seem to make a difference.
Max, a list member, suggested offline that it might have to do with type_transition, which does seem to make sense.
I tried both: type_transition rsync_t var_log_t : file rsync_log_t; and type_transition rsync_t var_log_t : file usr_t;
But neither worked (I have all the appropriate allows for those contexts).
Am I going down the right path here (type_transition)? Or does anyone else have a suggestion in terms of how the symlink can be used?
Can you try this policy module:
:::::::::::::: solr.fc :::::::::::::: /var/log/store(/.*)? gen_context(system_u:object_r:rsync_log_t,s0)
:::::::::::::: solr.te :::::::::::::: policy_module(solr, 0.0.1)
# ====================================================== # Declarations # ======================================================
require { type rsync_t; type rsync_log_t; }
# ====================================================== # Solr local policy # ======================================================
logging_log_file(rsync_log_t) logging_log_filetrans(rsync_t,rsync_log_t, { file dir } )
Followed by: # restorecon -rv /var/log/store
See if that helps.
Paul.
Paul Howarth wrote:
On Mon, 07 Jul 2008 13:01:55 -0400 Johnny Tan linuxweb@gmail.com wrote:
Johnny Tan wrote:
I'm stumped.
I run a Java app called Solr, which does search indexing. My solr server creates the index, then I have a bunch of solr clients that rsync that index over.
The rsync itself is fine, that works. The problem is it won't write to the appropriate logfile, which is: /opt/solr/logs/rsyncd.log
/opt/solr/logs is a symlink to /var/log/store.
A little bit more information that might help solve this...
If I remove the symlink, and /opt/solr/bin/rsyncd-start runs (which basically starts rsyncd), then rsyncd can write to /opt/solr/logs/rsyncd.log with no problems.
If I put the symlink back in (to /var/log/store), then it fails (again, with no AVC messages).
The only difference I can see between /opt/solr/logs (as a directory) and /var/log/store is the default contexts, for /opt/solr/logs, it's root:object_r:usr_t, for /var/log/store it's root:object_r:var_log_t
When I put the symlink back, I tried changing the context of /var/log/store to root:object_r:usr_t to match /opt/solr/logs, but that doesn't seem to make a difference.
Max, a list member, suggested offline that it might have to do with type_transition, which does seem to make sense.
I tried both: type_transition rsync_t var_log_t : file rsync_log_t; and type_transition rsync_t var_log_t : file usr_t;
But neither worked (I have all the appropriate allows for those contexts).
Am I going down the right path here (type_transition)? Or does anyone else have a suggestion in terms of how the symlink can be used?
Can you try this policy module:
:::::::::::::: solr.fc :::::::::::::: /var/log/store(/.*)? gen_context(system_u:object_r:rsync_log_t,s0)
==
# semanage fcontext -a -t rsync_log_t "/var/log/store(/.*)?" libsepol.context_from_record: type rsync_log_t is not defined libsepol.context_from_record: could not create context structure libsemanage.validate_handler: invalid context system_u:object_r:rsync_log_t:s0 specified for /var/log/store(/.*)? [all files] libsemanage.dbase_llist_iterate: could not iterate over records /usr/sbin/semanage: Could not add file context for /var/log/store(/.*)?
==
It seems rsync_log_t is not defined. Can I somehow do this without having rsync_log_t?
It works fine when I don't use a symlink, so I assume rsync_log_t is not necessary for this to work.
But I need the symlink because I need the files to be stored in /var/log/store, as opposed to /opt/solr/logs.
johnn
On Tue, 08 Jul 2008 16:36:13 -0400 Johnny Tan linuxweb@gmail.com wrote:
Paul Howarth wrote:
On Mon, 07 Jul 2008 13:01:55 -0400 Johnny Tan linuxweb@gmail.com wrote:
Johnny Tan wrote:
I'm stumped.
I run a Java app called Solr, which does search indexing. My solr server creates the index, then I have a bunch of solr clients that rsync that index over.
The rsync itself is fine, that works. The problem is it won't write to the appropriate logfile, which is: /opt/solr/logs/rsyncd.log
/opt/solr/logs is a symlink to /var/log/store.
A little bit more information that might help solve this...
If I remove the symlink, and /opt/solr/bin/rsyncd-start runs (which basically starts rsyncd), then rsyncd can write to /opt/solr/logs/rsyncd.log with no problems.
If I put the symlink back in (to /var/log/store), then it fails (again, with no AVC messages).
The only difference I can see between /opt/solr/logs (as a directory) and /var/log/store is the default contexts, for /opt/solr/logs, it's root:object_r:usr_t, for /var/log/store it's root:object_r:var_log_t
When I put the symlink back, I tried changing the context of /var/log/store to root:object_r:usr_t to match /opt/solr/logs, but that doesn't seem to make a difference.
Max, a list member, suggested offline that it might have to do with type_transition, which does seem to make sense.
I tried both: type_transition rsync_t var_log_t : file rsync_log_t; and type_transition rsync_t var_log_t : file usr_t;
But neither worked (I have all the appropriate allows for those contexts).
Am I going down the right path here (type_transition)? Or does anyone else have a suggestion in terms of how the symlink can be used?
Can you try this policy module:
:::::::::::::: solr.fc :::::::::::::: /var/log/store(/.*)? gen_context(system_u:object_r:rsync_log_t,s0)
==
# semanage fcontext -a -t rsync_log_t "/var/log/store(/.*)?" libsepol.context_from_record: type rsync_log_t is not defined libsepol.context_from_record: could not create context structure libsemanage.validate_handler: invalid context system_u:object_r:rsync_log_t:s0 specified for /var/log/store(/.*)? [all files] libsemanage.dbase_llist_iterate: could not iterate over records /usr/sbin/semanage: Could not add file context for /var/log/store(/.*)?
==
It seems rsync_log_t is not defined. Can I somehow do this without having rsync_log_t?
It works fine when I don't use a symlink, so I assume rsync_log_t is not necessary for this to work.
But I need the symlink because I need the files to be stored in /var/log/store, as opposed to /opt/solr/logs.
I thought from earlier messages you were on RHEL 5? I've tested this module with CentOS 5.2 and it loads just fine.
Which policy version are you using?
Paul.
Paul Howarth wrote:
On Tue, 08 Jul 2008 16:36:13 -0400 Johnny Tan linuxweb@gmail.com wrote:
Paul Howarth wrote:
On Mon, 07 Jul 2008 13:01:55 -0400 Johnny Tan linuxweb@gmail.com wrote:
Johnny Tan wrote:
I'm stumped.
I run a Java app called Solr, which does search indexing. My solr server creates the index, then I have a bunch of solr clients that rsync that index over.
The rsync itself is fine, that works. The problem is it won't write to the appropriate logfile, which is: /opt/solr/logs/rsyncd.log
/opt/solr/logs is a symlink to /var/log/store.
A little bit more information that might help solve this...
If I remove the symlink, and /opt/solr/bin/rsyncd-start runs (which basically starts rsyncd), then rsyncd can write to /opt/solr/logs/rsyncd.log with no problems.
If I put the symlink back in (to /var/log/store), then it fails (again, with no AVC messages).
The only difference I can see between /opt/solr/logs (as a directory) and /var/log/store is the default contexts, for /opt/solr/logs, it's root:object_r:usr_t, for /var/log/store it's root:object_r:var_log_t
When I put the symlink back, I tried changing the context of /var/log/store to root:object_r:usr_t to match /opt/solr/logs, but that doesn't seem to make a difference.
Max, a list member, suggested offline that it might have to do with type_transition, which does seem to make sense.
I tried both: type_transition rsync_t var_log_t : file rsync_log_t; and type_transition rsync_t var_log_t : file usr_t;
But neither worked (I have all the appropriate allows for those contexts).
Am I going down the right path here (type_transition)? Or does anyone else have a suggestion in terms of how the symlink can be used?
Can you try this policy module:
:::::::::::::: solr.fc :::::::::::::: /var/log/store(/.*)? gen_context(system_u:object_r:rsync_log_t,s0)
==
# semanage fcontext -a -t rsync_log_t "/var/log/store(/.*)?" libsepol.context_from_record: type rsync_log_t is not defined libsepol.context_from_record: could not create context structure libsemanage.validate_handler: invalid context system_u:object_r:rsync_log_t:s0 specified for /var/log/store(/.*)? [all files] libsemanage.dbase_llist_iterate: could not iterate over records /usr/sbin/semanage: Could not add file context for /var/log/store(/.*)?
==
It seems rsync_log_t is not defined. Can I somehow do this without having rsync_log_t?
It works fine when I don't use a symlink, so I assume rsync_log_t is not necessary for this to work.
But I need the symlink because I need the files to be stored in /var/log/store, as opposed to /opt/solr/logs.
I thought from earlier messages you were on RHEL 5? I've tested this module with CentOS 5.2 and it loads just fine.
Which policy version are you using?
selinux-policy-2.4.6-106.el5_1.3
I haven't updated yet to 5.2
johnn
On Tue, 08 Jul 2008 16:51:24 -0400 Johnny Tan linuxweb@gmail.com wrote:
Paul Howarth wrote:
On Tue, 08 Jul 2008 16:36:13 -0400 Johnny Tan linuxweb@gmail.com wrote:
Paul Howarth wrote:
On Mon, 07 Jul 2008 13:01:55 -0400 Johnny Tan linuxweb@gmail.com wrote:
Johnny Tan wrote:
I'm stumped.
I run a Java app called Solr, which does search indexing. My solr server creates the index, then I have a bunch of solr clients that rsync that index over.
The rsync itself is fine, that works. The problem is it won't write to the appropriate logfile, which is: /opt/solr/logs/rsyncd.log
/opt/solr/logs is a symlink to /var/log/store.
A little bit more information that might help solve this...
If I remove the symlink, and /opt/solr/bin/rsyncd-start runs (which basically starts rsyncd), then rsyncd can write to /opt/solr/logs/rsyncd.log with no problems.
If I put the symlink back in (to /var/log/store), then it fails (again, with no AVC messages).
The only difference I can see between /opt/solr/logs (as a directory) and /var/log/store is the default contexts, for /opt/solr/logs, it's root:object_r:usr_t, for /var/log/store it's root:object_r:var_log_t
When I put the symlink back, I tried changing the context of /var/log/store to root:object_r:usr_t to match /opt/solr/logs, but that doesn't seem to make a difference.
Max, a list member, suggested offline that it might have to do with type_transition, which does seem to make sense.
I tried both: type_transition rsync_t var_log_t : file rsync_log_t; and type_transition rsync_t var_log_t : file usr_t;
But neither worked (I have all the appropriate allows for those contexts).
Am I going down the right path here (type_transition)? Or does anyone else have a suggestion in terms of how the symlink can be used?
Can you try this policy module:
:::::::::::::: solr.fc :::::::::::::: /var/log/store(/.*)? gen_context(system_u:object_r:rsync_log_t,s0)
==
# semanage fcontext -a -t rsync_log_t "/var/log/store(/.*)?" libsepol.context_from_record: type rsync_log_t is not defined libsepol.context_from_record: could not create context structure libsemanage.validate_handler: invalid context system_u:object_r:rsync_log_t:s0 specified for /var/log/store(/.*)? [all files] libsemanage.dbase_llist_iterate: could not iterate over records /usr/sbin/semanage: Could not add file context for /var/log/store(/.*)?
==
It seems rsync_log_t is not defined. Can I somehow do this without having rsync_log_t?
It works fine when I don't use a symlink, so I assume rsync_log_t is not necessary for this to work.
But I need the symlink because I need the files to be stored in /var/log/store, as opposed to /opt/solr/logs.
I thought from earlier messages you were on RHEL 5? I've tested this module with CentOS 5.2 and it loads just fine.
Which policy version are you using?
selinux-policy-2.4.6-106.el5_1.3
I haven't updated yet to 5.2
Try adding the type definition to the top of the policy module (just after the "policy_module" line):
type rsync_log_t; logging_log_file(rsync_log_t)
Paul.
johnn
Paul Howarth wrote:
It seems rsync_log_t is not defined. Can I somehow do this without having rsync_log_t?
It works fine when I don't use a symlink, so I assume rsync_log_t is not necessary for this to work.
But I need the symlink because I need the files to be stored in /var/log/store, as opposed to /opt/solr/logs.
I thought from earlier messages you were on RHEL 5? I've tested this module with CentOS 5.2 and it loads just fine.
Which policy version are you using?
selinux-policy-2.4.6-106.el5_1.3
I haven't updated yet to 5.2
Try adding the type definition to the top of the policy module (just after the "policy_module" line):
type rsync_log_t; logging_log_file(rsync_log_t)
That still didn't recognize rsync_log_t. But I went ahead and upgraded to 5.2, and my original selinux policy works -- it doesn't use rsync_log_t at all.
My (completely wild) guess is that something with symlinks ("class lnk_file") got fixed in the new policy, but I don't know what.
Thanks for the help though!
johnn
Johnny Tan wrote:
Paul Howarth wrote:
It seems rsync_log_t is not defined. Can I somehow do this without having rsync_log_t?
It works fine when I don't use a symlink, so I assume rsync_log_t is not necessary for this to work.
But I need the symlink because I need the files to be stored in /var/log/store, as opposed to /opt/solr/logs.
I thought from earlier messages you were on RHEL 5? I've tested this module with CentOS 5.2 and it loads just fine.
Which policy version are you using?
selinux-policy-2.4.6-106.el5_1.3
I haven't updated yet to 5.2
Try adding the type definition to the top of the policy module (just after the "policy_module" line):
type rsync_log_t; logging_log_file(rsync_log_t)
That still didn't recognize rsync_log_t. But I went ahead and upgraded to 5.2, and my original selinux policy works -- it doesn't use rsync_log_t at all.
Question:
Is it ok to update ONLY selinux-policy to the version that comes with 5.2 (and library, etc., dependencies) WITHOUT upgrading the kernel and everything else to their 5.2 versions?
johnn
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Johnny Tan wrote: | Johnny Tan wrote: |> Paul Howarth wrote: |>>>>> It seems rsync_log_t is not defined. Can I somehow do this without |>>>>> having rsync_log_t? |>>>>> |>>>>> It works fine when I don't use a symlink, so I assume rsync_log_t |>>>>> is not necessary for this to work. |>>>>> |>>>>> But I need the symlink because I need the files to be stored in |>>>>> /var/log/store, as opposed to /opt/solr/logs. |>>>> I thought from earlier messages you were on RHEL 5? I've tested this |>>>> module with CentOS 5.2 and it loads just fine. |>>>> |>>>> Which policy version are you using? |>>> selinux-policy-2.4.6-106.el5_1.3 |>>> |>>> I haven't updated yet to 5.2 |>> |>> Try adding the type definition to the top of the policy module (just |>> after the "policy_module" line): |>> |>> type rsync_log_t; |>> logging_log_file(rsync_log_t) |> |> That still didn't recognize rsync_log_t. But I went ahead and upgraded |> to 5.2, and my original selinux policy works -- it doesn't use |> rsync_log_t at all. | | Question: | | Is it ok to update ONLY selinux-policy to the version that comes with | 5.2 (and library, etc., dependencies) WITHOUT upgrading the kernel and | everything else to their 5.2 versions? | Yes | johnn | | -- | fedora-selinux-list mailing list | fedora-selinux-list@redhat.com | https://www.redhat.com/mailman/listinfo/fedora-selinux-list
On Tue, Jul 08, 2008 at 05:57:48PM -0400, Johnny Tan wrote:
My (completely wild) guess is that something with symlinks ("class lnk_file") got fixed in the new policy, but I don't know what.
symlinks + SELinux are difficult to deal with. It is MUCH easier to just use bind mounts:
mount --bind /opt/solr/logs /var/log/store
in /etc/fstab:
/opt/solr/logs /var/log/store none bind 0 0
selinux@lists.fedoraproject.org
-
Chuck Anderson -
Daniel J Walsh -
John Dennis -
Johnny Tan -
Paul Howarth -
Stephen Smalley