Re: [RFC][PATCH] locks: Allow disabling mandatory locking at compile time

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jeff Layton <jeff.layton@xxxxxxxxxxxxxxx> writes:

>> Given the general concensus of this thread it looks like we will also
>> want this incremental patch to deal with the user namespace case.
>> 
>> From: "Eric W. Biederman" <ebiederm@xxxxxxxxxxxx>
>> Date: Wed, 11 Nov 2015 17:18:07 -0600
>> Subject: [PATCH] locks: Don't allow mounts in user namespaces to enable mandatory locking
>> 
>> Since no one uses mandatory locking and files with mandatory locks can
>> cause problems don't allow them in user namespaces.
>> 
>> Signed-off-by: "Eric W. Biederman" <ebiederm@xxxxxxxxxxxx>
>> ---
>>  fs/namespace.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/fs/namespace.c b/fs/namespace.c
>> index dee44b4791f0..95a349d5003d 100644
>> --- a/fs/namespace.c
>> +++ b/fs/namespace.c
>> @@ -1589,7 +1589,7 @@ static inline bool may_mandlock(void)
>>  #ifndef	CONFIG_MANDATORY_FILE_LOCKING
>>  	return false;
>>  #endif
>> -	return true;
>> +	return capable(CAP_SYS_ADMIN);
>>  }
>>  
>>  /*
>
> Fair enough. I'll merge that as well and we'll see what breaks.

Sounds good.  If something breaks just revert this bit.

The ways things work today is not an issue if people are actually using
mandatory file locking.


The fundamental issues that triggered my looking into this was a single
threaded server that accepts input from unprivileged users and hangs if
reading that input takes too long.  Mandatory locking just made it
easier to supply an input that hangs.

There are a countless other ways to make reading lots of data from a
file descriptor slow, the obvious ones being cpu load, disk load (for
local filesystems), and network load (for network filesystems).

Passing file descriptors appears to be the only path where mandatory
locking from files in a user namespace can affect processes outside of
the user namespace.  Given that there are many other ways to trigger a
slow file descriptor, that mandatory locking problems are easy to avoid,
I just can not see the existing kernel behavior as being wrong.

The current state of affairs is a problem in that we have a feature in
the kernel that apparently no one uses and everyone ignores.   Turning
off the feature is the right solution for that.

There is a privileged operation involved with enabling "-o mand" on
a filesystem.  The intent and the only value I can see in the "-o mand"
flag is that it determines if a filesystem will interpret the a specific
combinationation of file mode bits as specifying mandatory locking on a
file.  Allowing that on files accessible only to users inside of the user
namespace will not cause problems for the rest of the system except
potentially with passed file descriptors.

Eric
_______________________________________________
Containers mailing list
Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/containers



[Index of Archives]     [Cgroups]     [Netdev]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux