SELinux question

[Zoltan Boszormenyi]

Paul Howarth írta:
> On Sun, 2006-05-28 at 22:14 +0200, Zoltan Boszormenyi wrote:
>   
>> Paul Howarth írta:
>>     
>>> On Sun, 2006-05-28 at 20:33 +0200, Zoltan Boszormenyi wrote:
>>>   
>>>       
>>>> Paul Howarth írta:
>>>>     
>>>>         
>>>>> On Sun, 2006-05-28 at 17:13 +0200, Zoltan Boszormenyi wrote:
>>>>>   
>>>>>       
>>>>>           
>>>>>> Hi,
>>>>>>
>>>>>> answering to myself. :-)
>>>>>>
>>>>>> Zoltan Boszormenyi írta:
>>>>>>     
>>>>>>         
>>>>>>             
>>>>>>> So, how can I fix the current situation and include /home1/pgsql in
>>>>>>> the postgresql context/domain? I would like to relabel it to recover 
>>>>>>> the context...
>>>>>>>
>>>>>>> BTW the same principle would apply if one would like to create
>>>>>>> another tablespace for postgresql under another mount point...
>>>>>>>       
>>>>>>>           
>>>>>>>               
>>>>>> After some more RTFM, it would seem simple:
>>>>>>
>>>>>> semanage fcontext -a -t postgresql_db_t '/home1/pgsql/data(/.*)?'
>>>>>> semanage fcontext -a -t postgresql_log_t '/home1/pgsql/pgstartup.log'
>>>>>> fixfiles relabel /home1/pgsql
>>>>>>
>>>>>> But it was not enough. Starting it with "service postgresql start" fails.
>>>>>> I had to modify the rc script, too. I had to replace /var/lib/pgsql with
>>>>>> /home1/pgsql everywhere despite the /var/lib/pgsql -> /home1/pgsql symlink.
>>>>>>     
>>>>>>         
>>>>>>             
>>>>> This will be failing because SELinux is blocking access to reading the
>>>>> symlink. You should find an avc denial for the lnk_file in your logs.
>>>>>   
>>>>>       
>>>>>           
>>>> I haven't found any. :-(
>>>>     
>>>>         
>>> Perhaps you won't find any now because it's never trying to
>>> access /var/lib/pgsql since you changed the configs to get around the
>>> problem? Are there none from first attempt?
>>>   
>>>       
>> Sorry, I expected the audit messages in /var/log/messages.
>> Yes, I have such messages in audit.log:
>>     
>
> You must have auditd running (probably a system upgraded from FC4 rather
> than a clean FC5 install).
>   

Actually, no. I was a clean install over my previous FC3.
I installed and set auditd to run.

>> type=AVC msg=audit(1148827118.909:2493): avc:  denied  { read } \
>>    for  pid=29719 comm="postmaster" name="pgsql" dev=hdb3 \
>>    ino=1010804 scontext=user_u:system_r:postgresql_t:s0 \
>>    tcontext=user_u:object_r:var_lib_t:s0 tclass=lnk_file
>> type=PATH msg=audit(1148827118.909:2493): item=0 \
>>    name="/var/lib/pgsql/data/postgresql.conf" flags=101
>>     
>
> ...
>
>   
>>> The existence of the symlink itself is probably the problem, rather than
>>> its context. Applications have to have specific permission to be able to
>>> read (and hence follow) symlinks in SELinux.
>>>   
>>>       
>> So, how can I tweak the policy so postgres can follow just this one symlink?
>>     
>
> Set yourself up for making local policy modules:
>
> # yum install checkpolicy
> # cd /root
> # mkdir selinux.local
> # cd selinux.local
> # chcon -R -t usr_t .
> # ln -s /usr/share/selinux/devel/Makefile .
>
> Make a local policy module for this issue, in this directory:
> 1. Create a file postgres.te with this content:
>
> module postgres 0.1;
>
> require {
>         class lnk_file read;
>
>         type postgresql_t;
>         type var_lib_t;
> };
>
> # Allow postgres to read /var/lib/pgsql -> /home1/pgsql symlink
> allow postgresql_t var_lib_t:lnk_file read;
>
> 2. Create a file postgres.fc with this content:
>
> /home1/pgsql[^/]*/data(/.*)?
> gen_context(system_u:object_r:postgresql_db_t,s0)
>
> /home1/pgsql[^/]*/pgstartup.log	--
> gen_context(system_u:object_r:postgresql_log_t,s0)
>
> (that's two long lines)
>
> 3. Create an empty postgres.if file:
>
> # touch postgres.if
>
> 4. Build the policy module
>
> # make
>
> Next, remove any file context objects you added for this issue using
> semanage (contexts will now be managed using your local policy module):
>
> # semanage fcontext -d -t postgresql_db_t '/home1/pgsql/data(/.*)?'
> # semanage fcontext -d -t postgresql_log_t '/home1/pgsql/pgstartup.log'
> # semanage fcontext -d -t postgresql_db_t '/home1/pgsql2/data(/.*)?'
>
> Finally, install your new policy module:
>
> # semodule -i postgres.pp
>   

Thanks, it almost worked. After doing these above,
I still got avc denied { search } messages like this below:

type=AVC msg=audit(1148979521.381:10): avc:  denied  { search } for  
pid=2666 comm="postmaster" name="/" dev=sda1 ino=2 
scontext=system_u:system_r:postgresql_t:s0 
tcontext=system_u:object_r:default_t:s0 tclass=dir

As it turned out, /home1 was default_t and postgresql is not enabled to 
search
and read files in default_t context. It made it working:

# semanage fcontext -a -t var_lib_t -f -d '/home1'
# fixfiles relabel /home1

What puzzled me is starting postgresql failed at boot
but not the manual "service postgresql start" after bootup.
(Maybe different contexts are applied to the logged-in root
and the init program?)
The two lines above made it working again.

>>>>> An easier way is to bind mount /home/pgsql on /var/lib/pgsql etc. and do
>>>>> a restorecon -R on the "new" /var/lib/pgsql. That achieves the same
>>>>> effect without the symlink.
>>>>>           

Actually I missed the "bind mount" part. That would have been much easier.
But the crash course in SELinux was most fruitful, thank you.

      

>>>> I know, but the disk I install will be (or already is) used for both my 
>>>> databases
>>>> and for extending /home. I created only one partition on that disk, so...
>>>> The system is my home/devel machine and the disk is SATA and fast enough.
>>>> Although for a high performance production machine, I would always give
>>>> PostgreSQL it's own disks to separate WAL, table and index spaces.
>>>>     
>>>>         
>>> Perhaps you'll use LVM next time :-)
>>>   
>>>       
>> Well, how can you merge two disks with LVM and still
>> be able to record from the BTTV card to only one of them?
>> Having a separate disk dedicates the disk speed to this task
>> while another program can write under /home. Maybe
>> my knowledge is a bit outdated, so enlightenment is welcome. :-)
>>     
>
> You could create two partitions on the additional disk, one for
> extending the space on /home and one dedicated to BTTV. Create an LVM
> physical volume on each partition. Add the first physical volume to the
> volume group used for /home, then extend the logical volume for /home
> and resize up the partition. Create a new volume group for BTTV purposes
> and add the second physical volume to it. Create a new logical volume
> for BTTV, and create a new filesystem on that logical volume. Since it's
> in a separate volume group, it will be allocated space only from the
> fast new drive.
>   

Thanks for this info. Next time I reinstall my machine (FC6?)
I will do a similar scheme.

Sorry for the late answer, yesterday I donated my blood
and had to hit the bed earlier that my usual.

Best regards,
Zoltán Böszörményi