From: Rich Kulawiec <rsk@gsp.org>
To: linux-kernel@vger.kernel.org
Cc: Eric Paris <eparis@redhat.com>
Subject: Re: Friendlier EPERM - Request for input
Date: Sun, 27 Jan 2013 09:16:39 -0500 [thread overview]
Message-ID: <20130127141639.GA3028@gsp.org> (raw)
In-Reply-To: <1357835679.1342.45.camel@localhost>
On Thu, Jan 10, 2013 at 11:34:39AM -0500, Eric Paris wrote:
> This is not the point I am arguing. This is not about LSMs, how hard
> they are to configure, or how to 'fix' them. It certainly isn't about
> how one LSM is better, easier, or superior to another. This is about
> getting more information in userspace when operations fail. I'll quote
> an off list e-mail I received:
>
> Friendlier/more complete error messages would eliminate an awful lot of
> digging around trying to figure *what* the problem is, preparatory to
> discerning *where* the problem is and *how* to fix it.
I know I'm a bit late to this, but Eric's quoting me, and I thought
I should stand behind my words publicly.
I often find myself confronted with systems that I didn't build, haven't
maintained, have no documentation for, and are broken in odd/puzzling
ways. There's also sometimes a bit of duress due to externally imposed
time constraints. I of course don't expect anyone else to solve those
problems, but it would be awfully handy if there was a breadcrumb trail
to follow.
So to borrow Eric's phrase, "getting more information in userspace when
operations fail", would be an entirely good thing. I'll defer entirely to
others in the discussion thread about how that might be best accomplished,
but I'd like to express my full support for the end goal.
---rsk
next prev parent reply other threads:[~2013-01-27 14:33 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-09 16:04 Friendlier EPERM - Request for input Eric Paris
2013-01-09 19:43 ` Eric Paris
2013-01-09 20:14 ` Casey Schaufler
2013-01-09 20:32 ` Eric Paris
2013-01-09 20:53 ` Casey Schaufler
2013-01-09 20:59 ` Jakub Jelinek
2013-01-09 21:09 ` Eric Paris
2013-01-09 22:17 ` Carlos O'Donell
2013-01-21 0:00 ` Eric W. Biederman
2013-01-21 0:59 ` Eric W. Biederman
2013-01-21 1:09 ` Mike Frysinger
2013-01-09 21:12 ` Casey Schaufler
2013-01-09 21:13 ` Eric Paris
2013-01-09 21:36 ` Casey Schaufler
2013-01-10 15:14 ` Tetsuo Handa
2013-01-10 16:34 ` Eric Paris
2013-01-11 13:00 ` Mimi Zohar
2013-01-12 5:08 ` Tetsuo Handa
2013-01-27 14:16 ` Rich Kulawiec [this message]
2013-01-12 7:23 ` Rob Landley
2013-01-12 20:27 ` Dr. David Alan Gilbert
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=20130127141639.GA3028@gsp.org \
--to=rsk@gsp.org \
--cc=eparis@redhat.com \
--cc=linux-kernel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox