From: Yauheni Kaliuta <yauheni.kaliuta@redhat.com>
To: Lucas De Marchi <lucas.de.marchi@gmail.com>
Cc: linux-modules <linux-modules@vger.kernel.org>
Subject: Re: [PATCHv2 0/4] depmod: implement external directories support
Date: Tue, 20 Jun 2017 12:11:50 +0300 [thread overview]
Message-ID: <xunyzid3f2g9.fsf@redhat.com> (raw)
In-Reply-To: <20170509190924.9087-1-yauheni.kaliuta@redhat.com> (Yauheni Kaliuta's message of "Tue, 9 May 2017 22:09:20 +0300")
Hi!
>>>>> On Tue, 9 May 2017 22:09:20 +0300, Yauheni Kaliuta wrote:
> This is a pretty simple extention of existing logic, since now
> depmod already is able to:
> a) scan modules with full path from command line without -a
> switch;
> b) detects broken symbol dependencies and broken modversions,
> what assumes, that modules are already are not built for the
> existing kernel.
[...]
I've heared a concern about the feature, that it may make sense to limit
the possible external directories to some subdirectory(s). The idea is that
3rd party vendor packages can pollute filesystem with its modules and a
system administrator may like to be sure that they are in a more defined
place.
What do you think?
Of course, it is not security concern, just about unintentional
pollution. If there is the intention, in most cases from the package
maintainer scipts it's possible to install symbolic link under the
permitted directory, for example, with the file anywere.
--
WBR,
Yauheni Kaliuta
next prev parent reply other threads:[~2017-06-20 9:11 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-23 15:23 [PATCH RFC 0/3] depmod: implement external directories support Yauheni Kaliuta
2016-11-23 15:23 ` [PATCH RFC 1/3] depmod: create depmod dir independent search function Yauheni Kaliuta
2017-05-09 6:56 ` Lucas De Marchi
2016-11-23 15:23 ` [PATCH RFC 2/3] depmod: search key: move builtin detection under the add function Yauheni Kaliuta
2017-05-09 7:04 ` Lucas De Marchi
2016-11-23 15:23 ` [PATCH RFC 3/3] depmod: implement external directories support Yauheni Kaliuta
2017-03-18 21:46 ` [PATCH RFC 0/3] " Yauheni Kaliuta
2017-05-09 7:51 ` Lucas De Marchi
2017-05-09 8:50 ` Yauheni Kaliuta
2017-05-09 19:09 ` [PATCHv2 0/4] " Yauheni Kaliuta
2017-05-09 19:09 ` [PATCHv2 1/4] depmod: create depmod dir independent search function Yauheni Kaliuta
2017-06-02 2:18 ` Lucas De Marchi
2017-05-09 19:09 ` [PATCHv2 2/4] depmod: rewrite depmod modules search with scratchbuf Yauheni Kaliuta
2017-06-02 3:23 ` Lucas De Marchi
2017-05-09 19:09 ` [PATCHv2 3/4] depmod: implement external directories support Yauheni Kaliuta
2017-06-02 3:30 ` Lucas De Marchi
2017-05-09 19:09 ` [PATCHv2 4/4] testsuite: add tests for external directory support Yauheni Kaliuta
2017-06-02 4:03 ` Lucas De Marchi
2017-06-02 4:05 ` [PATCHv2 0/4] depmod: implement external directories support Lucas De Marchi
2017-06-20 9:11 ` Yauheni Kaliuta [this message]
2017-07-19 18:07 ` Lucas De Marchi
2017-07-19 18:57 ` Yauheni Kaliuta
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xunyzid3f2g9.fsf@redhat.com \
--to=yauheni.kaliuta@redhat.com \
--cc=linux-modules@vger.kernel.org \
--cc=lucas.de.marchi@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).