rsyncd can't open log file, but there are no avc messages

[Johnny Tan]

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 };

[Paul Howarth]

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.

[Johnny Tan]

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

[John Dennis]

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 <jdennis(a)redhat.com&gt;

[Johnny Tan]

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

[Stephen Smalley]

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.

-- 
Stephen Smalley
National Security Agency

[Johnny Tan]

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

[Paul Howarth]

On Mon, 07 Jul 2008 13:01:55 -0400
Johnny Tan <linuxweb(a)gmail.com&gt; 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]

On Mon, 07 Jul 2008 13:01:55 -0400
Johnny Tan <linuxweb(a)gmail.com&gt; 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.

[Johnny Tan]

Paul Howarth wrote:
>  On Mon, 07 Jul 2008 13:01:55 -0400
>  Johnny Tan <linuxweb(a)gmail.com&gt; 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

[Paul Howarth]

On Tue, 08 Jul 2008 16:36:13 -0400
Johnny Tan <linuxweb(a)gmail.com&gt; wrote:

>  Paul Howarth wrote:
>  > On Mon, 07 Jul 2008 13:01:55 -0400
>  > Johnny Tan <linuxweb(a)gmail.com&gt; 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.

[Johnny Tan]

Paul Howarth wrote:
>  On Tue, 08 Jul 2008 16:36:13 -0400
>  Johnny Tan <linuxweb(a)gmail.com&gt; wrote:
>  
> > Paul Howarth wrote:
> >> On Mon, 07 Jul 2008 13:01:55 -0400
> >> Johnny Tan <linuxweb(a)gmail.com&gt; 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

[Paul Howarth]

On Tue, 08 Jul 2008 16:51:24 -0400
Johnny Tan <linuxweb(a)gmail.com&gt; wrote:

>  Paul Howarth wrote:
>  > On Tue, 08 Jul 2008 16:36:13 -0400
>  > Johnny Tan <linuxweb(a)gmail.com&gt; wrote:
>  > 
>  >> Paul Howarth wrote:
>  >>> On Mon, 07 Jul 2008 13:01:55 -0400
>  >>> Johnny Tan <linuxweb(a)gmail.com&gt; 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
>

[Johnny Tan]

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]

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

[Chuck Anderson]

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

[Daniel J Walsh]

-----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(a)redhat.com
| https://www.redhat.com/mailman/listinfo/fedora-selinux-list

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkh0wjkACgkQrlYvE4MpobOMlgCgg4t9GiG/3YDOTliINaaOuXMa
> gxIAn079tVvoEgMLQXmK2fxMfckroMEZ
> =y1mH
> -----END PGP SIGNATURE-----