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 informa
On Sunday 20 January 2013 19:00:46 Eric W. Biederman wrote:
> Carlos O'Donell writes:
> > On 01/09/2013 04:09 PM, Eric Paris wrote:
> >> On Wed, 2013-01-09 at 21:59 +0100, Jakub Jelinek wrote:
> >>> On Wed, Jan 09, 2013 at 12:53:40PM -0800, Casey Schaufler wrote:
> I'm suggesting that the stri
ebied...@xmission.com (Eric W. Biederman) writes:
> Carlos O'Donell writes:
>
>> On 01/09/2013 04:09 PM, Eric Paris wrote:
>>> On Wed, 2013-01-09 at 21:59 +0100, Jakub Jelinek wrote:
On Wed, Jan 09, 2013 at 12:53:40PM -0800, Casey Schaufler wrote:
> I'm suggesting that the string returne
Carlos O'Donell writes:
> On 01/09/2013 04:09 PM, Eric Paris wrote:
>> On Wed, 2013-01-09 at 21:59 +0100, Jakub Jelinek wrote:
>>> On Wed, Jan 09, 2013 at 12:53:40PM -0800, Casey Schaufler wrote:
I'm suggesting that the string returned by get_extended_error_info()
ought to be the audit
* Eric Paris (epa...@redhat.com) wrote:
> Getting an EPERM/EACCES in userspace really kinda blows. As a user you
> don't have any idea why you got it. It could be SELinux, it could be
> rwx bits on the file, it could be a missing capability, it could be an
> ACL, it could be who knows what. We'd
On 01/09/2013 10:04:23 AM, Eric Paris wrote:
Getting an EPERM/EACCES in userspace really kinda blows. As a user
you
don't have any idea why you got it. It could be SELinux, it could be
rwx bits on the file, it could be a missing capability, it could be an
ACL, it could be who knows what.
Ad
Eric Paris wrote:
> On Fri, 2013-01-11 at 00:14 +0900, Tetsuo Handa wrote:
> > The reason I think is that people turn off LSMs because they are using LSMs
> > without understanding "what the current configuration is" and/or "how to
> > change
> > configuration". People do not spend (or cannot affo
On Thu, 2013-01-10 at 11:34 -0500, Eric Paris wrote:
> 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.
Agreed, add to the mix of existing issues,
On Fri, 2013-01-11 at 00:14 +0900, Tetsuo Handa wrote:
> The reason I think is that people turn off LSMs because they are using LSMs
> without understanding "what the current configuration is" and/or "how to
> change
> configuration". People do not spend (or cannot afford spending) resources for
>
Eric Paris wrote:
> On systems with a strict security policy worried about such things this
> would quite reasonably need to be disabled. But most of the reason
> people turn off LSMs is because it gets in the way and they get pissed
> getting an EPERM, checking rwx bits, having no idea WTF happen
On 01/09/2013 04:09 PM, Eric Paris wrote:
> On Wed, 2013-01-09 at 21:59 +0100, Jakub Jelinek wrote:
>> On Wed, Jan 09, 2013 at 12:53:40PM -0800, Casey Schaufler wrote:
>>> I'm suggesting that the string returned by get_extended_error_info()
>>> ought to be the audit record the system call would gen
On Wed, 2013-01-09 at 21:59 +0100, Jakub Jelinek wrote:
> On Wed, Jan 09, 2013 at 12:53:40PM -0800, Casey Schaufler wrote:
> > I'm suggesting that the string returned by get_extended_error_info()
> > ought to be the audit record the system call would generate, regardless
> > of whether the audit sy
On 1/9/2013 1:13 PM, Eric Paris wrote:
> On Wed, 2013-01-09 at 12:53 -0800, Casey Schaufler wrote:
>
>> Let me try again, I think I didn't quite get the idea across.
>>
>> I'm suggesting that the string returned by get_extended_error_info()
>> ought to be the audit record the system call would gene
On Wed, Jan 09, 2013 at 12:53:40PM -0800, Casey Schaufler wrote:
> I'm suggesting that the string returned by get_extended_error_info()
> ought to be the audit record the system call would generate, regardless
> of whether the audit system would emit it or not.
What system call would that info be
On Wed, 2013-01-09 at 12:53 -0800, Casey Schaufler wrote:
> Let me try again, I think I didn't quite get the idea across.
>
> I'm suggesting that the string returned by get_extended_error_info()
> ought to be the audit record the system call would generate, regardless
> of whether the audit syste
On 1/9/2013 12:59 PM, Jakub Jelinek wrote:
> On Wed, Jan 09, 2013 at 12:53:40PM -0800, Casey Schaufler wrote:
>> I'm suggesting that the string returned by get_extended_error_info()
>> ought to be the audit record the system call would generate, regardless
>> of whether the audit system would emit
On 1/9/2013 12:32 PM, Eric Paris wrote:
> On Wed, 2013-01-09 at 12:14 -0800, Casey Schaufler wrote:
>> On 1/9/2013 11:43 AM, Eric Paris wrote:
>>> I know many people are worried about information leaks, so I'll right up
>>> front say lets add the sysctl to disable the interface for those who are
>>
On Wed, 2013-01-09 at 12:14 -0800, Casey Schaufler wrote:
> On 1/9/2013 11:43 AM, Eric Paris wrote:
> > I know many people are worried about information leaks, so I'll right up
> > front say lets add the sysctl to disable the interface for those who are
> > concerned about the metadata information
On 1/9/2013 11:43 AM, Eric Paris wrote:
>> On Wed, 2013-01-09 at 11:04 -0500, Eric Paris wrote:
>>> Getting an EPERM/EACCES in userspace really kinda blows. As a user you
>>> don't have any idea why you got it.
> Stephen Smalley wrote:
>> What if the denial was due to lacking sufficient permissi
>On Wed, 2013-01-09 at 11:04 -0500, Eric Paris wrote:
> >Getting an EPERM/EACCES in userspace really kinda blows. As a user you
> >don't have any idea why you got it.
Stephen Smalley wrote:
> What if the denial was due to lacking sufficient permission to stat
> the file (in which case you shoul
20 matches
Mail list logo
