My apologies for those receiving this post a 2nd time. The original
post never made it the mailing lists ...
On Fri, 2014-04-25 at 15:25 -0700, Eric W. Biederman wrote:
> Al Viro writes:
>
> > On Fri, Apr 25, 2014 at 02:43:42PM -0700, Eric W. Biederman wrote:
> >
> >> ssize_t
My apologies for those receiving this post a 2nd time. The original
post never made it the mailing lists ...
On Fri, 2014-04-25 at 15:25 -0700, Eric W. Biederman wrote:
Al Viro v...@zeniv.linux.org.uk writes:
On Fri, Apr 25, 2014 at 02:43:42PM -0700, Eric W. Biederman wrote:
ssize_t
On 26 April 2014 20:42, Al Viro wrote:
> On Sat, Apr 26, 2014 at 07:54:47PM +0300, Dmitry Kasatkin wrote:
>> On 26 April 2014 16:56, Al Viro wrote:
>> > On Sat, Apr 26, 2014 at 11:58:45AM +0300, Dmitry Kasatkin wrote:
>> >
>> >> Conflict with Apparmor means with Ubuntu.
>> >>
>> >> But answering
On Sat, Apr 26, 2014 at 07:54:47PM +0300, Dmitry Kasatkin wrote:
> On 26 April 2014 16:56, Al Viro wrote:
> > On Sat, Apr 26, 2014 at 11:58:45AM +0300, Dmitry Kasatkin wrote:
> >
> >> Conflict with Apparmor means with Ubuntu.
> >>
> >> But answering to your early question..
> >> IMA does not want
On 26 April 2014 16:56, Al Viro wrote:
> On Sat, Apr 26, 2014 at 11:58:45AM +0300, Dmitry Kasatkin wrote:
>
>> Conflict with Apparmor means with Ubuntu.
>>
>> But answering to your early question..
>> IMA does not want permission denied when measuring and re-measuring files.
>> may_open() is
On Sat, Apr 26, 2014 at 11:58:45AM +0300, Dmitry Kasatkin wrote:
> Conflict with Apparmor means with Ubuntu.
>
> But answering to your early question..
> IMA does not want permission denied when measuring and re-measuring files.
> may_open() is doing that job before.
>
> We need quickly
On 26 April 2014 01:38, Eric W. Biederman wrote:
> Dmitry Kasatkin writes:
>
>> Is it really a show stopper to switch order of 2 functions as quick fix?
>> It was like that before 3.10 and seemed ok...
>
> When that is the question. The answer is yes it is a show stopper.
>
> A quick fix to
On 26 April 2014 01:11, Eric W. Biederman wrote:
> Dmitry Kasatkin writes:
>
>> On 26 April 2014 00:27, Eric W. Biederman wrote:
>>> Dmitry Kasatkin writes:
>>>
On 25 April 2014 23:45, Eric W. Biederman wrote:
> Dmitry Kasatkin writes:
>
>> On 25 April 2014 23:01, Oleg
On 26 April 2014 01:11, Eric W. Biederman ebied...@xmission.com wrote:
Dmitry Kasatkin dmitry.kasat...@gmail.com writes:
On 26 April 2014 00:27, Eric W. Biederman ebied...@xmission.com wrote:
Dmitry Kasatkin dmitry.kasat...@gmail.com writes:
On 25 April 2014 23:45, Eric W. Biederman
On 26 April 2014 01:38, Eric W. Biederman ebied...@xmission.com wrote:
Dmitry Kasatkin dmitry.kasat...@gmail.com writes:
Is it really a show stopper to switch order of 2 functions as quick fix?
It was like that before 3.10 and seemed ok...
When that is the question. The answer is yes it is
On Sat, Apr 26, 2014 at 11:58:45AM +0300, Dmitry Kasatkin wrote:
Conflict with Apparmor means with Ubuntu.
But answering to your early question..
IMA does not want permission denied when measuring and re-measuring files.
may_open() is doing that job before.
We need quickly introduce
On 26 April 2014 16:56, Al Viro v...@zeniv.linux.org.uk wrote:
On Sat, Apr 26, 2014 at 11:58:45AM +0300, Dmitry Kasatkin wrote:
Conflict with Apparmor means with Ubuntu.
But answering to your early question..
IMA does not want permission denied when measuring and re-measuring files.
On Sat, Apr 26, 2014 at 07:54:47PM +0300, Dmitry Kasatkin wrote:
On 26 April 2014 16:56, Al Viro v...@zeniv.linux.org.uk wrote:
On Sat, Apr 26, 2014 at 11:58:45AM +0300, Dmitry Kasatkin wrote:
Conflict with Apparmor means with Ubuntu.
But answering to your early question..
IMA does
On 26 April 2014 20:42, Al Viro v...@zeniv.linux.org.uk wrote:
On Sat, Apr 26, 2014 at 07:54:47PM +0300, Dmitry Kasatkin wrote:
On 26 April 2014 16:56, Al Viro v...@zeniv.linux.org.uk wrote:
On Sat, Apr 26, 2014 at 11:58:45AM +0300, Dmitry Kasatkin wrote:
Conflict with Apparmor means with
Dmitry Kasatkin writes:
> Is it really a show stopper to switch order of 2 functions as quick fix?
> It was like that before 3.10 and seemed ok...
When that is the question. The answer is yes it is a show stopper.
A quick fix to bury a fundamental design flaw because the code
previously
Al Viro writes:
> On Fri, Apr 25, 2014 at 02:43:42PM -0700, Eric W. Biederman wrote:
>
>> ssize_t __vfs_read(struct file *file, char __user *buf, size_t count, loff_t
>> *pos)
>> {
>> ssize_t ret;
>>
>> if (!(file->f_mode & FMODE_READ))
>> return -EBADF;
>> if
Dmitry Kasatkin writes:
> On 26 April 2014 00:27, Eric W. Biederman wrote:
>> Dmitry Kasatkin writes:
>>
>>> On 25 April 2014 23:45, Eric W. Biederman wrote:
Dmitry Kasatkin writes:
> On 25 April 2014 23:01, Oleg Nesterov wrote:
>> On 04/25, Eric W. Biederman wrote:
On 26 April 2014 00:46, Dmitry Kasatkin wrote:
> On 26 April 2014 00:27, Eric W. Biederman wrote:
>> Dmitry Kasatkin writes:
>>
>>> On 25 April 2014 23:45, Eric W. Biederman wrote:
Dmitry Kasatkin writes:
> On 25 April 2014 23:01, Oleg Nesterov wrote:
>> On 04/25, Eric W.
On Fri, Apr 25, 2014 at 02:43:42PM -0700, Eric W. Biederman wrote:
> ssize_t __vfs_read(struct file *file, char __user *buf, size_t count, loff_t
> *pos)
> {
> ssize_t ret;
>
> if (!(file->f_mode & FMODE_READ))
> return -EBADF;
> if (!file->f_op->read &&
On 26 April 2014 00:27, Eric W. Biederman wrote:
> Dmitry Kasatkin writes:
>
>> On 25 April 2014 23:45, Eric W. Biederman wrote:
>>> Dmitry Kasatkin writes:
>>>
On 25 April 2014 23:01, Oleg Nesterov wrote:
> On 04/25, Eric W. Biederman wrote:
>>
>> Oleg Nesterov writes:
Al Viro writes:
> On Fri, Apr 25, 2014 at 01:45:17PM -0700, Eric W. Biederman wrote:
>
>> IMA-appraisal is fundamentally broken because I can take a mandatory
>> file lock and prevent IMA-apprasial.
>>
>> Using kernel_read is what allows this.
>>
>> > Isn't it a clear motivating case???
>>
>>
Dmitry Kasatkin writes:
> On 25 April 2014 23:45, Eric W. Biederman wrote:
>> Dmitry Kasatkin writes:
>>
>>> On 25 April 2014 23:01, Oleg Nesterov wrote:
On 04/25, Eric W. Biederman wrote:
>
> Oleg Nesterov writes:
>
> > Well. I _think_ that __fput() and ima_file_free()
On Fri, Apr 25, 2014 at 01:45:17PM -0700, Eric W. Biederman wrote:
> IMA-appraisal is fundamentally broken because I can take a mandatory
> file lock and prevent IMA-apprasial.
>
> Using kernel_read is what allows this.
>
> > Isn't it a clear motivating case???
>
> kernel_read is not
On 25 April 2014 23:45, Eric W. Biederman wrote:
> Dmitry Kasatkin writes:
>
>> On 25 April 2014 23:01, Oleg Nesterov wrote:
>>> On 04/25, Eric W. Biederman wrote:
Oleg Nesterov writes:
> Well. I _think_ that __fput() and ima_file_free() in particular should
> not
Dmitry Kasatkin writes:
> On 25 April 2014 23:01, Oleg Nesterov wrote:
>> On 04/25, Eric W. Biederman wrote:
>>>
>>> Oleg Nesterov writes:
>>>
>>> > Well. I _think_ that __fput() and ima_file_free() in particular should not
>>> > depend on current and/or current->nsproxy. If nothing else,
On 25 April 2014 23:01, Oleg Nesterov wrote:
> On 04/25, Eric W. Biederman wrote:
>>
>> Oleg Nesterov writes:
>>
>> > Well. I _think_ that __fput() and ima_file_free() in particular should not
>> > depend on current and/or current->nsproxy. If nothing else, fput() can be
>> > called by the
On 04/25, Eric W. Biederman wrote:
>
> Oleg Nesterov writes:
>
> > Well. I _think_ that __fput() and ima_file_free() in particular should not
> > depend on current and/or current->nsproxy. If nothing else, fput() can be
> > called by the unrelated task which looks into /proc/pid/.
> >
> > But
Oleg Nesterov writes:
> On 04/25, Eric W. Biederman wrote:
>>
>> Oleg Nesterov writes:
>>
>> > Eric, this makes me think again that we should do exit_task_namespaces()
>> > after exit_task_work(). We already discussed this before, but this looks
>> > like another indication this change makes
On 04/25, Eric W. Biederman wrote:
>
> Oleg Nesterov writes:
>
> > Eric, this makes me think again that we should do exit_task_namespaces()
> > after exit_task_work(). We already discussed this before, but this looks
> > like another indication this change makes sense.
>
> I know you mentioned
Oleg Nesterov writes:
> On 04/25, Dmitry Kasatkin wrote:
>>
>> On 25/04/14 16:00, Dmitry Kasatkin wrote:
>> > Hello,
>> >
>> > I discovered a kernel panic on system running Ubuntu when IMA is enabled.
>> > It happens on reboot.
>> >
>> > --
>> > [ 106.750100] NSPROXY is
On 04/25, Dmitry Kasatkin wrote:
>
> On 25/04/14 16:00, Dmitry Kasatkin wrote:
> > Hello,
> >
> > I discovered a kernel panic on system running Ubuntu when IMA is enabled.
> > It happens on reboot.
> >
> > --
> > [ 106.750100] NSPROXY is NULL: error.log
On 25/04/14 16:00, Dmitry Kasatkin wrote:
> Hello,
>
> I discovered a kernel panic on system running Ubuntu when IMA is enabled.
> It happens on reboot.
>
> --
> [ 106.750100] NSPROXY is NULL: error.log (/var/log/mysql/error.log)
> [ 106.750167] BUG: unable to handle kernel
Hello,
I discovered a kernel panic on system running Ubuntu when IMA is enabled.
It happens on reboot.
--
[ 106.750100] NSPROXY is NULL: error.log (/var/log/mysql/error.log)
[ 106.750167] BUG: unable to handle kernel NULL pointer dereference at
0018
[
Hello,
I discovered a kernel panic on system running Ubuntu when IMA is enabled.
It happens on reboot.
--
[ 106.750100] NSPROXY is NULL: error.log (/var/log/mysql/error.log)
[ 106.750167] BUG: unable to handle kernel NULL pointer dereference at
0018
[
On 25/04/14 16:00, Dmitry Kasatkin wrote:
Hello,
I discovered a kernel panic on system running Ubuntu when IMA is enabled.
It happens on reboot.
--
[ 106.750100] NSPROXY is NULL: error.log (/var/log/mysql/error.log)
[ 106.750167] BUG: unable to handle kernel NULL
On 04/25, Dmitry Kasatkin wrote:
On 25/04/14 16:00, Dmitry Kasatkin wrote:
Hello,
I discovered a kernel panic on system running Ubuntu when IMA is enabled.
It happens on reboot.
--
[ 106.750100] NSPROXY is NULL: error.log (/var/log/mysql/error.log)
[
Oleg Nesterov o...@redhat.com writes:
On 04/25, Dmitry Kasatkin wrote:
On 25/04/14 16:00, Dmitry Kasatkin wrote:
Hello,
I discovered a kernel panic on system running Ubuntu when IMA is enabled.
It happens on reboot.
--
[ 106.750100] NSPROXY is NULL: error.log
On 04/25, Eric W. Biederman wrote:
Oleg Nesterov o...@redhat.com writes:
Eric, this makes me think again that we should do exit_task_namespaces()
after exit_task_work(). We already discussed this before, but this looks
like another indication this change makes sense.
I know you
Oleg Nesterov o...@redhat.com writes:
On 04/25, Eric W. Biederman wrote:
Oleg Nesterov o...@redhat.com writes:
Eric, this makes me think again that we should do exit_task_namespaces()
after exit_task_work(). We already discussed this before, but this looks
like another indication this
On 04/25, Eric W. Biederman wrote:
Oleg Nesterov o...@redhat.com writes:
Well. I _think_ that __fput() and ima_file_free() in particular should not
depend on current and/or current-nsproxy. If nothing else, fput() can be
called by the unrelated task which looks into /proc/pid/.
But
On 25 April 2014 23:01, Oleg Nesterov o...@redhat.com wrote:
On 04/25, Eric W. Biederman wrote:
Oleg Nesterov o...@redhat.com writes:
Well. I _think_ that __fput() and ima_file_free() in particular should not
depend on current and/or current-nsproxy. If nothing else, fput() can be
called
Dmitry Kasatkin dmitry.kasat...@gmail.com writes:
On 25 April 2014 23:01, Oleg Nesterov o...@redhat.com wrote:
On 04/25, Eric W. Biederman wrote:
Oleg Nesterov o...@redhat.com writes:
Well. I _think_ that __fput() and ima_file_free() in particular should not
depend on current and/or
On 25 April 2014 23:45, Eric W. Biederman ebied...@xmission.com wrote:
Dmitry Kasatkin dmitry.kasat...@gmail.com writes:
On 25 April 2014 23:01, Oleg Nesterov o...@redhat.com wrote:
On 04/25, Eric W. Biederman wrote:
Oleg Nesterov o...@redhat.com writes:
Well. I _think_ that __fput() and
On Fri, Apr 25, 2014 at 01:45:17PM -0700, Eric W. Biederman wrote:
IMA-appraisal is fundamentally broken because I can take a mandatory
file lock and prevent IMA-apprasial.
Using kernel_read is what allows this.
Isn't it a clear motivating case???
kernel_read is not appropriate for
Dmitry Kasatkin dmitry.kasat...@gmail.com writes:
On 25 April 2014 23:45, Eric W. Biederman ebied...@xmission.com wrote:
Dmitry Kasatkin dmitry.kasat...@gmail.com writes:
On 25 April 2014 23:01, Oleg Nesterov o...@redhat.com wrote:
On 04/25, Eric W. Biederman wrote:
Oleg Nesterov
Al Viro v...@zeniv.linux.org.uk writes:
On Fri, Apr 25, 2014 at 01:45:17PM -0700, Eric W. Biederman wrote:
IMA-appraisal is fundamentally broken because I can take a mandatory
file lock and prevent IMA-apprasial.
Using kernel_read is what allows this.
Isn't it a clear motivating
On 26 April 2014 00:27, Eric W. Biederman ebied...@xmission.com wrote:
Dmitry Kasatkin dmitry.kasat...@gmail.com writes:
On 25 April 2014 23:45, Eric W. Biederman ebied...@xmission.com wrote:
Dmitry Kasatkin dmitry.kasat...@gmail.com writes:
On 25 April 2014 23:01, Oleg Nesterov
On Fri, Apr 25, 2014 at 02:43:42PM -0700, Eric W. Biederman wrote:
ssize_t __vfs_read(struct file *file, char __user *buf, size_t count, loff_t
*pos)
{
ssize_t ret;
if (!(file-f_mode FMODE_READ))
return -EBADF;
if (!file-f_op-read !file-f_op-aio_read)
On 26 April 2014 00:46, Dmitry Kasatkin dmitry.kasat...@gmail.com wrote:
On 26 April 2014 00:27, Eric W. Biederman ebied...@xmission.com wrote:
Dmitry Kasatkin dmitry.kasat...@gmail.com writes:
On 25 April 2014 23:45, Eric W. Biederman ebied...@xmission.com wrote:
Dmitry Kasatkin
Dmitry Kasatkin dmitry.kasat...@gmail.com writes:
On 26 April 2014 00:27, Eric W. Biederman ebied...@xmission.com wrote:
Dmitry Kasatkin dmitry.kasat...@gmail.com writes:
On 25 April 2014 23:45, Eric W. Biederman ebied...@xmission.com wrote:
Dmitry Kasatkin dmitry.kasat...@gmail.com writes:
Al Viro v...@zeniv.linux.org.uk writes:
On Fri, Apr 25, 2014 at 02:43:42PM -0700, Eric W. Biederman wrote:
ssize_t __vfs_read(struct file *file, char __user *buf, size_t count, loff_t
*pos)
{
ssize_t ret;
if (!(file-f_mode FMODE_READ))
return -EBADF;
if
Dmitry Kasatkin dmitry.kasat...@gmail.com writes:
Is it really a show stopper to switch order of 2 functions as quick fix?
It was like that before 3.10 and seemed ok...
When that is the question. The answer is yes it is a show stopper.
A quick fix to bury a fundamental design flaw because
52 matches
Mail list logo
