Bug 430929 - lspp modification to xinetd calling getfilecon with incorrect path
lspp modification to xinetd calling getfilecon with incorrect path
Product: Fedora
Classification: Fedora
Component: xinetd (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Jan Safranek
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-01-30 12:26 EST by Joe Nall
Modified: 2008-01-31 10:20 EST (History)
1 user (show)

See Also:
Fixed In Version: xinetd-2.3.14-18.fc9
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-01-31 10:20:15 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Patch to use correct path in getfilecon (402 bytes, text/x-patch)
2008-01-30 12:28 EST, Joe Nall
no flags Details

  None (edit)
Description Joe Nall 2008-01-30 12:26:29 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20071213 Fedora/ Firefox/

Description of problem:
getfilecon is being called with the basename of a path rather than the full path. This causes the new context computation to fail.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
Use flags=LABELED and nonstandard path

service auth
        disable         = no
        socket_type     = stream
        wait            = no
        user            = nobody
        instances       = UNLIMITED
        per_source      = UNLIMITED
        server          = /opt/foo/libexec/identd
        protocol        = tcp
        flags           = LABELED

Actual Results:
Process launch fails with context errors

Expected Results:
Process should be launched at label of connection and with computed type.

Additional info:
Comment 1 Joe Nall 2008-01-30 12:28:26 EST
Created attachment 293455 [details]
Patch to use correct path in getfilecon

Use SC_SERVER(scp) instead of SC_SERVER_ARGV( scp )[0]
Comment 2 Jan Safranek 2008-01-31 08:35:37 EST
Steve, could you please help me with this one? The patch looks harmless, but I
am not able to test it without a day wasted by studying selinux and IPsec
documentation and setting this up. The SELinux part of xinetd is your work, right?
Comment 3 Steve Grubb 2008-01-31 09:45:50 EST
Jan, this patch looks OK. It should, in theory, do the same thing.
Comment 4 Jan Safranek 2008-01-31 10:20:15 EST
Thanks Steve, now let's prove the theory in the real world.

Note You need to log in before you can comment on or make changes to this bug.