linux-kernel - Re: [RFC] [PATCH] hugetlbfs :shmget with SHM

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <473DA25B.2000702@linux.vnet.ibm.com>
Date:	Fri, 16 Nov 2007 19:29:55 +0530
From:	Ciju Rajan K <ciju@...ux.vnet.ibm.com>
To:	aglitke <agl@...ibm.com>
CC:	linux-kernel@...r.kernel.org, wli@...omorphy.com
Subject: Re: [RFC] [PATCH] hugetlbfs :shmget with SHM_HUGETLB only works as
 root

Hi  Adam,
 If this condition check is not included, the root user have to use the 
function
 setrlimit() to set the lock_limit of a normal user to RLIM_INFINITY.  I 
think
 the /proc interface 'hugetlb_shm_group' is introduced to avoid these 
difficulties.
 Please correct me, if I am wrong.

 Regarding the problem with the 'if' condition, I feel that even in the 
case of
 user's lock_limit is set to unlimited, he could use unlimited hugepages and
 normal page shm segments. So what is the advantage in this scenario.

 I tried to avoid the #ifdef statements. But the variable 
sysctl_hugetlb_shm_group is defined
 in fs/hugetlbfs/inode.c, this segment is enabled only when the config 
parameter
 CONFIG_HUGETLBFS is set to yes. If the hugetlbfs is  not selected while 
configuring,
 there would be a compilation error.

 Is there any better way so that the root user can configure the gid in 
'hugetlb_shm_group'
 and the user is able to access the huge pages using shmget().

Thanks
Ciju

aglitke wrote:
> Hi Ciju:
>
> I am still not exactly sure why this patch is needed.  As I read
> user_shm_lock():
>
>   
>> lock_limit = current->signal->rlim[RLIMIT_MEMLOCK].rlim_cur;
>> if (lock_limit == RLIM_INFINITY)
>> 	allowed = 1;
>> lock_limit >>= PAGE_SHIFT;
>> spin_lock(&shmlock_user_lock);
>> if (!allowed &&
>>     locked + user->locked_shm > lock_limit && !capable(CAP_IPC_LOCK))
>> 	goto out;
>>     
>
> ... if the user's locked limit (ulimit -l) is set to unlimited, allowed
> (above) is set to 1.  In that case, the second part of that if() is
> bypassed, and the function grants permission.  Therefore, the easy
> solution is to make sure your user's lock_limit is RLIM_INFINITY.
>
> On Wed, 2007-11-14 at 19:45 +0530, Ciju Rajan K wrote:
> <snip>
>   
>> @@ -248,8 +249,14 @@ int user_shm_lock(size_t size, struct us
>>          allowed = 1;
>>      lock_limit >>= PAGE_SHIFT;
>>      spin_lock(&shmlock_user_lock);
>> +#ifdef CONFIG_HUGETLB_PAGE
>> +    if (!allowed &&
>> +        locked + user->locked_shm > lock_limit &&
>> +        (!(capable(CAP_IPC_LOCK) || in_group_p(sysctl_hugetlb_shm_group))))
>>     
>
> This will allow any user in hugetlb_shm_group to make unlimited use of
> huge page shm segments _and_ normal page shm segments.  Definitely not
> what you want.
>
>   
>> +#else
>>      if (!allowed &&
>>          locked + user->locked_shm > lock_limit && !capable(CAP_IPC_LOCK))
>> +#endif
>>          goto out;
>>      get_uid(user);
>>      user->locked_shm += locked;
>>
>>     
>
> Please don't add new #ifdefs into .c files, headers only.
>
>   

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/