Re: SELinux question

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 2006-05-31 at 19:40 +0200, Zoltan Boszormenyi wrote: 
> Paul Howarth írta:
> > Zoltan Boszormenyi wrote:
> >> Paul Howarth írta:
> >>> Zoltan Boszormenyi wrote:
> >>>> Paul Howarth írta:
> >>>>> Zoltan Boszormenyi wrote:
> >>>>>> 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?)
> >>>>>
> >>>>> Running the initscript should be exactly the same as the boot 
> >>>>> process. Starting the service manually (without the initscript) 
> >>>>> would be different though, as no domain transition would happen.
> >>>>
> >>>> Both
> >>>>
> >>>> service postgresql start
> >>>>
> >>>> and
> >>>>
> >>>> su - postgres
> >>>> PGDATA=/home1/pgsql pg_ctl start
> >>>>
> >>>> started successfully if I logged in as root or under "su -" from my 
> >>>> mortal uid.
> >>>> (The postgresql initscript uses "runuser" instead of "su" IIRC.)
> >>>>
> >>>>> Do the AVCs logged during the boot process show the process 
> >>>>> running as postgresql_t? If you do a "ps uaxZ", is it running as 
> >>>>> postgresql_t or unconfined_t?
> >>>>
> >>>> It's running under postgresql_t.
> >>>
> >>> Does it run under postgresql_t if you start it using pg_ctl?
> >>
> >> $ su -
> >> # service postgresql stop
> >> # su - postgres
> >> $ PGDATA=/var/lib/pgsql/data pg_ctl start
> >> postmaster starting
> >> $ ps axuZ | grep post | grep -v bash | grep -v grep | grep -v "su -" 
> >> | grep -v "ps "
> >> user_u:system_r:unconfined_t    postgres  5171  0.5  0.3  92280  3808 
> >> pts/0    S    18:32   0:00 /usr/bin/postmaster
> >> user_u:system_r:unconfined_t    postgres  5174  0.0  0.1  81324  1056 
> >> pts/0    S    18:32   0:00 postgres: logger process
> >> user_u:system_r:unconfined_t    postgres  5176  0.0  0.1  92264  1152 
> >> pts/0    S    18:32   0:00 postgres: writer process
> >> user_u:system_r:unconfined_t    postgres  5177  0.0  0.1  82460   992 
> >> pts/0    S    18:32   0:00 postgres: stats buffer process
> >> user_u:system_r:unconfined_t    postgres  5178  0.0  0.1  81456  1196 
> >> pts/0    S    18:32   0:00 postgres: stats collector process
> >> $ pg_ctl stop
> >> $ logout
> >
> > That one's as I expected.
> >
> >> # service postgresql start
> >> A(z) postgresql szolgáltatás elindítása:                   [  OK  ]
> >> [root@host-81-17-177-202 ~]# ps axuZ | grep post | grep -v bash | 
> >> grep -v grep | grep -v "su -" | grep -v "ps "
> >> user_u:system_r:unconfined_t    postgres  5307  9.5  0.3  92284  3808 
> >> ?        S    18:36   0:00 /usr/bin/postmaster -p 5432 -D 
> >> /var/lib/pgsql/data
> >> user_u:system_r:unconfined_t    postgres  5309  0.0  0.1  81328  1056 
> >> ?        S    18:36   0:00 postgres: logger process
> >> user_u:system_r:unconfined_t    postgres  5311  0.0  0.1  92268  1112 
> >> ?        S    18:36   0:00 postgres: writer process
> >> user_u:system_r:unconfined_t    postgres  5312  0.0  0.0  82464   920 
> >> ?        S    18:36   0:00 postgres: stats buffer process
> >> user_u:system_r:unconfined_t    postgres  5313  0.0  0.1  81460  1196 
> >> ?        S    18:36   0:00 postgres: stats collector process
> >>
> >> Both times it's running under unconfined_t, so it doesn't matter
> >> whether it's running under "su - postgres" or "runuser - postgres".
> >> It seems what matters is that it's started from a logged in user:
> >
> > I'd have expected this to run as postgresql_t
> >
> > Is your postgresql initscript correctly labelled as initrc_exec_t?
> 
> Unfortunately not:
> 
> # ls --context postgresql
> -rwxr-xr-x  root     root     user_u:object_r:etc_t            postgresql
> 
> although other rc scripts are. Relabelled.

That explains the failure to transition to the postgresql_t domain then.

> # service postgresql restart
> A(z) postgresql szolgáltatás leállítása:                   [  OK  ]
> A(z) postgresql szolgáltatás elindítása:                   [  OK  ]
> # ps axuZ | grep post | grep -v bash | grep -v grep | grep -v "su -" | 
> grep -v "ps "
> user_u:system_r:postgresql_t    postgres 12617  1.2  0.3  92280  3808 
> ?        S    19:22   0:00 /usr/bin/postmaster -p 5432 -D 
> /var/lib/pgsql/data
> user_u:system_r:postgresql_t    postgres 12623  0.0  0.1  81324  1056 
> ?        S    19:22   0:00 postgres: logger process
> user_u:system_r:postgresql_t    postgres 12625  0.0  0.1  92264  1148 
> ?        S    19:22   0:00 postgres: writer process
> user_u:system_r:postgresql_t    postgres 12626  0.0  0.1  82460   992 
> ?        S    19:22   0:00 postgres: stats buffer process
> user_u:system_r:postgresql_t    postgres 12627  0.0  0.1  81456  1196 
> ?        S    19:22   0:00 postgres: stats collector process
> 
> Now it is postgresql_t.

Good.

> It must have been "joe", the editor I used
> for modifying the rc script. It renamed the original to postgresql~
> and created a new file with the modified content. The new file
> got some default policy from the directory it resides in.
> Should I always use "vi" to edit such config files? It saves the
> file in place. Or joe needs some fixup.

Well initscripts aren't really config files and I don't think they
should be edited at all. If they need to provide configurability, it
should be done by editing something under /etc/sysconfig, e.g. by
setting a PGDATA variable in (say) /etc/sysconfig/postgresql (I don't
know if the postgresql initscript has such a facility though). The file
under /etc/sysconfig can be sourced by the initscript to get the config
info.

Having said that, I believe vi will edit the file in place by default.
It's what I use for most of my editing tasks anyway.

> > What's the state of the postgresql_disable_trans boolean?
> > # getsebool postgresql_disable_trans
> 
> # getsebool postgresql_disable_trans
> postgresql_disable_trans --> off

That was the other possible cause of the transition failure.

Paul.



[Index of Archives]     [Current Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux