All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel J Walsh <dwalsh@redhat.com>
To: "Karel Zak" <kzak@redhat.com>, "Pádraig Brady" <P@draigBrady.com>
Cc: Fridolin Pokorny <fpokorny@redhat.com>,
	util-linux <util-linux@vger.kernel.org>,
	Bernhard Voelker <mail@bernhard-voelker.de>,
	bug-gnulib <bug-gnulib@gnu.org>, Coreutils <coreutils@gnu.org>
Subject: Re: large overhead in libmount
Date: Tue, 07 Apr 2015 07:00:06 -0400	[thread overview]
Message-ID: <5523B8B6.1030401@redhat.com> (raw)
In-Reply-To: <20150407102921.GH3923@ws.net.home>


On 04/07/2015 06:29 AM, Karel Zak wrote:
> On Thu, Apr 02, 2015 at 12:36:33PM +0100, Pádraig Brady wrote:
>>>> $ ldd src/du
>>>> linux-vdso.so.1 =>  (0x00007fff76ca8000)
>>>> libc.so.6 => /lib64/libc.so.6 (0x00007f2a1f742000)
>>>> /lib64/ld-linux-x86-64.so.2 (0x00007f2a1fd61000)
>>>>  libmount.so.1 => /lib64/libmount.so.1 (0x00007f2a1faff000)
>>>>   libblkid.so.1 => /lib64/libblkid.so.1 (0x00007f2a1f501000)
>>>>   libuuid.so.1 => /lib64/libuuid.so.1 (0x00007f2a1f2fc000)
>>>>   libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f2a1f0d7000)
>>>>   libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f2a1ee69000)
>>>>   liblzma.so.5 => /lib64/liblzma.so.5 (0x00007f2a1ec44000)
>>>>   libdl.so.2 => /lib64/libdl.so.2 (0x00007f2a1ea40000)
>>>>   libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f2a1e823000)
>>> The problem is libselinux, but on selinux based system you have all the
>>> libraries already in memory for many another tools...
>> Indeed.
>>
>> I see libmount links with libselinux to use selinux_trans_to_raw_context()
>> for the context= mount options etc.
> The ideal solution would be to avoid this selinux context translation
> at all. It would be nice to make it possible to send context= to kernel 
> as specified on command line. Dan, any comment? (dwalsh added to CC:)
>
> It's also painful that so generic (often used) library like selinux
> has so many additional dependencies.
This allows the user of an MLS system to execute

mount /dev/sda5 -o context="system_u:object_r:httpd_sys_content_t:TopSecret"

I agree that it is seldom used but it is critical for this customer.
>> I suppose one could split libmount
>> to avoid that dependency, though it's probably not worth it for this case at least?
> Well, I can create a fallback for this stuff and move the translation code to
> mount(8) only... then libmount will be without the dependence.
>
>     Karel
>
Putting this into mount versus libmount would probably be fine.

      reply	other threads:[~2015-04-07 11:00 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <54A321DC.4020300@bernhard-voelker.de>
2015-01-20  2:01 ` large overhead in libmount Pádraig Brady
2015-04-02 10:05   ` Karel Zak
2015-04-02 11:36     ` Pádraig Brady
2015-04-07 10:29       ` Karel Zak
2015-04-07 11:00         ` Daniel J Walsh [this message]

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=5523B8B6.1030401@redhat.com \
    --to=dwalsh@redhat.com \
    --cc=P@draigBrady.com \
    --cc=bug-gnulib@gnu.org \
    --cc=coreutils@gnu.org \
    --cc=fpokorny@redhat.com \
    --cc=kzak@redhat.com \
    --cc=mail@bernhard-voelker.de \
    --cc=util-linux@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.