Re: [PATCH] chcat: don't crash if access to binary policy is prohibited

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

 



On Sun, May 10, 2020 at 1:26 PM Nicolas Iooss <nicolas.iooss@xxxxxxx> wrote:
>
> On Sat, May 9, 2020 at 4:06 PM bauen1 <j2468h@xxxxxxxxxxxxxx> wrote:
> >
> > sobject will crash if access to the binary policy is prohibited by
> > selinux, e.g. refpolicy
> > this also breaks file operations that don't require seobject.
> >
> > Signed-off-by: bauen1 <j2468h@xxxxxxxxx>
>
> Hello,
> This patch looks very hackish. In fact, an underlying issue that
> exists with seobject is that "import seobject" raises an exception
> when it is used from an environment that is not allowed to read the
> policy:
>
> >>> import seobject
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
>   File "/usr/lib/python3.8/site-packages/seobject.py", line 33, in <module>
>     import sepolicy
>   File "/usr/lib/python3.8/site-packages/sepolicy/__init__.py", line
> 186, in <module>
>     raise e
>   File "/usr/lib/python3.8/site-packages/sepolicy/__init__.py", line
> 182, in <module>
>     policy_file = get_installed_policy()
>   File "/usr/lib/python3.8/site-packages/sepolicy/__init__.py", line
> 137, in get_installed_policy
>     raise ValueError(_("No SELinux Policy installed"))
> ValueError: No SELinux Policy installed
>
> Is this the issue you encountered when you write "seobject will crash"?
>
> In my humble opinion, trying to hide such an issue by moving "import
> seobject" makes maintaining the project more difficult. I would prefer
> seeing a way to allow using "import seobject" without raising
> exceptions, but working on this is unfortunately quite time-consuming
> (I have not seen a straightforward way to deal with this, and there
> exist several ways to solve this in not-very-direct ways, for example
> with lazy loading of the policy when needed or with replacing some API
> with stub functions if the policy cannot be loaded).
>
> Therefore I will not ack this patch, but I will not block ("Nack") it
> if another maintainer wants to include it.

I'm not opposed to the patch itself (I assume the current code breaks
usage of chcat under MLS policy by regular users who lack access to
the policy file), but your Signed-off-by line ought to be revised to
contain your real name. Otherwise, it doesn't really serve its
purpose.  See  the discussion of Signed-off-by in
https://www.kernel.org/doc/html/latest/process/submitting-patches.html.



[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux