Hi,
I have a small problem or I didn't find the correct info, in my Fedora 14 x86_64 and i686 machines when I restart a service by:
# service postfix restart or $ sudo service postfix restart
always the process runs under unconfined_u as per ps axZ | grep postfix
unconfined_u:system_r:postfix_master_t:s0 26602 ? Ss 0:00 /usr/libexec/postfix/master unconfined_u:system_r:postfix_pickup_t:s0 26604 ? S 0:00 pickup -l -t fifo -u unconfined_u:system_r:postfix_qmgr_t:s0 26605 ? S 0:00 qmgr -l -t fifo -u
and not under system_u as after a reboot
system_u:system_r:postfix_master_t:s0 1706 ? Ss 0:11 /usr/libexec/postfix/master system_u:system_r:postfix_qmgr_t:s0 1717 ? S 0:05 qmgr -l -t fifo -u system_u:system_r:postfix_master_t:s0 1822 ? S 0:01 tlsmgr -l -t unix -u system_u:system_r:postfix_pickup_t:s0 26061 ? S 0:00 pickup -l -t fifo -u
what can use to restart a service with the correct user context?
also sometimes I edit a file in /etc and after saving the context change from system_u to unconfined_u how can prevent that??,
thanks
Gabrielo
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/05/2011 03:19 AM, Gabriel Ramirez wrote:
Hi,
I have a small problem or I didn't find the correct info, in my Fedora 14 x86_64 and i686 machines when I restart a service by:
# service postfix restart or $ sudo service postfix restart
always the process runs under unconfined _u
Yes but that is the identity field in the security context tuple. It is not the type field. The identity field is used to map ( amongst categories/sensitivities ) roles to linux logins. The type field is used to enforce integrity.
In any case, You can ignore this issue, or you can use the run_init command when you manually (re) start a service (run_init service httpd)
In fedora no policy is enforced based upon the first field of the security context tuple. It is only used for mappings.
as per ps axZ | grep postfix
unconfined_u:system_r:postfix_master_t:s0 26602 ? Ss 0:00 /usr/libexec/postfix/master unconfined_u:system_r:postfix_pickup_t:s0 26604 ? S 0:00 pickup -l -t fifo -u unconfined_u:system_r:postfix_qmgr_t:s0 26605 ? S 0:00 qmgr -l -t fifo -u
and not under system_u as after a reboot
system_u:system_r:postfix_master_t:s0 1706 ? Ss 0:11 /usr/libexec/postfix/master system_u:system_r:postfix_qmgr_t:s0 1717 ? S 0:05 qmgr -l -t fifo -u system_u:system_r:postfix_master_t:s0 1822 ? S 0:01 tlsmgr -l -t unix -u system_u:system_r:postfix_pickup_t:s0 26061 ? S 0:00 pickup -l -t fifo -u
what can use to restart a service with the correct user context?
also sometimes I edit a file in /etc and after saving the context change from system_u to unconfined_u how can prevent that??,
thanks
Gabrielo
selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/04/2011 09:19 PM, Gabriel Ramirez wrote:
Hi,
I have a small problem or I didn't find the correct info, in my Fedora 14 x86_64 and i686 machines when I restart a service by:
# service postfix restart or $ sudo service postfix restart
always the process runs under unconfined_u as per ps axZ | grep postfix
unconfined_u:system_r:postfix_master_t:s0 26602 ? Ss 0:00 /usr/libexec/postfix/master unconfined_u:system_r:postfix_pickup_t:s0 26604 ? S 0:00 pickup -l -t fifo -u unconfined_u:system_r:postfix_qmgr_t:s0 26605 ? S 0:00 qmgr -l -t fifo -u
and not under system_u as after a reboot
system_u:system_r:postfix_master_t:s0 1706 ? Ss 0:11 /usr/libexec/postfix/master system_u:system_r:postfix_qmgr_t:s0 1717 ? S 0:05 qmgr -l -t fifo -u system_u:system_r:postfix_master_t:s0 1822 ? S 0:01 tlsmgr -l -t unix -u system_u:system_r:postfix_pickup_t:s0 26061 ? S 0:00 pickup -l -t fifo -u
what can use to restart a service with the correct user context?
also sometimes I edit a file in /etc and after saving the context change from system_u to unconfined_u how can prevent that??,
thanks
Gabrielo
selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
First off I would say it does not matter, or should not matter.
You could use run_init command to start it with the system_u user.
run_init service postfix restart
On 04/05/2011 07:44 AM, Daniel J Walsh wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/04/2011 09:19 PM, Gabriel Ramirez wrote:
Hi,
I have a small problem or I didn't find the correct info, in my Fedora 14 x86_64 and i686 machines when I restart a service by:
# service postfix restart or $ sudo service postfix restart
always the process runs under unconfined_u
First off I would say it does not matter, or should not matter.
ok, I was thinking if a bug existed when starting daemons under unconfined_u but I was wrong. thanks for your time.
Gabriel
You could use run_init command to start it with the system_u user.
run_init service postfix restart
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/06/2011 07:22 AM, Gabriel Ramirez wrote:
On 04/05/2011 07:44 AM, Daniel J Walsh wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/04/2011 09:19 PM, Gabriel Ramirez wrote:
Hi,
I have a small problem or I didn't find the correct info, in my Fedora 14 x86_64 and i686 machines when I restart a service by:
# service postfix restart or $ sudo service postfix restart
always the process runs under unconfined_u
First off I would say it does not matter, or should not matter.
ok, I was thinking if a bug existed when starting daemons under unconfined_u but I was wrong. thanks for your time.
I do not want to make this over-complicated but i want to mention it for reference purposes:
Policy can be build with the UBAC option. When UBAC is enabled then the first field in the security context tuple is used to enforce user based access control using constraints and so when policy is built with UBAC then the first field does matter. (Fedora does not build policy with UBAC enabled)
Gabriel
You could use run_init command to start it with the system_u user.
run_init service postfix restart
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
selinux@lists.fedoraproject.org