lkml.org 
[lkml]   [2014]   [Jun]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH v7 4/9] seccomp: move no_new_privs into seccomp
On Tue, Jun 24, 2014 at 12:30 PM, Oleg Nesterov <oleg@redhat.com> wrote:
> On 06/24, Andy Lutomirski wrote:
>>
>> On Tue, Jun 24, 2014 at 12:18 PM, Oleg Nesterov <oleg@redhat.com> wrote:
>> >>
>> >> -struct seccomp { };
>> >> +struct seccomp {
>> >> + unsigned long flags;
>> >> +};
>> >
>> > A bit messy ;)
>> >
>> > I am wondering if we can simply do
>> >
>> > static inline bool current_no_new_privs(void)
>> > {
>> > if (current->no_new_privs)
>> > return true;
>> >
>> > #ifdef CONFIG_SECCOMP
>> > if (test_thread_flag(TIF_SECCOMP))
>> > return true;
>> > #endif
>>
>> Nope -- privileged users can enable seccomp w/o nnp.
>
> Indeed, I am stupid.
>
> Still it would be nice to cleanup this somehow. The new member is only
> used as a previous ->no_new_privs, just it is long to allow the concurent
> set/get. Logically it doesn't even belong to seccomp{}.

We could add an unsigned long atomic flags field to task_struct.

Grr. Why isn't there an unsigned *int* atomic bitmask type? Even u64
would be better. unsigned long is useless.

>
> Oleg.
>



--
Andy Lutomirski
AMA Capital Management, LLC


\
 
 \ /
  Last update: 2014-06-24 22:21    [W:0.075 / U:0.048 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site