[refpolicy] [ devices patch 1/1] Fix dev_list_sysfs interface to allow domains to read sysfs lnk_file.

[refpolicy] [ devices patch 1/1] Fix dev_list_sysfs interface to allow domains to read sysfs lnk_file.

[Dominick Grift]

Signed-off-by: Dominick Grift <domg472@gmail.com>
---
:100644 100644 fe31e1f... 83c4a2a... M	policy/modules/kernel/devices.if
 policy/modules/kernel/devices.if |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/policy/modules/kernel/devices.if b/policy/modules/kernel/devices.if
index fe31e1f..83c4a2a 100644
--- a/policy/modules/kernel/devices.if
+++ b/policy/modules/kernel/devices.if
@@ -3322,6 +3322,7 @@ interface(`dev_list_sysfs',`
 	')
 
 	list_dirs_pattern($1, sysfs_t, sysfs_t)
+	allow $1 sysfs_t:lnk_file read_lnk_file_perms;
 ')
 
 ########################################
-- 
1.6.6.1

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20100226/f2452777/attachment.bin 

[refpolicy] [ devices patch 1/1] Fix dev_list_sysfs interface to allow domains to read sysfs lnk_file.

[Christopher J. PeBenito]

On Fri, 2010-02-26 at 11:39 +0100, Dominick Grift wrote:
> Signed-off-by: Dominick Grift <domg472@gmail.com>

I'm on the fence for this one.  Normally I think this is better suited
for dev_read_sysfs(), which has this perm already.  But since sysfs is
so highly linked, I suppose it could make sense.  What prompted this?

> ---
> :100644 100644 fe31e1f... 83c4a2a... M	policy/modules/kernel/devices.if
>  policy/modules/kernel/devices.if |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/policy/modules/kernel/devices.if b/policy/modules/kernel/devices.if
> index fe31e1f..83c4a2a 100644
> --- a/policy/modules/kernel/devices.if
> +++ b/policy/modules/kernel/devices.if
> @@ -3322,6 +3322,7 @@ interface(`dev_list_sysfs',`
>  	')
>  
>  	list_dirs_pattern($1, sysfs_t, sysfs_t)
> +	allow $1 sysfs_t:lnk_file read_lnk_file_perms;
>  ')
>  
>  ########################################
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150

[refpolicy] [ devices patch 1/1] Fix dev_list_sysfs interface to allow domains to read sysfs lnk_file.

[Dominick Grift]

On 03/04/2010 04:53 PM, Christopher J. PeBenito wrote:
> On Fri, 2010-02-26 at 11:39 +0100, Dominick Grift wrote:
>> Signed-off-by: Dominick Grift <domg472@gmail.com>
> 
> I'm on the fence for this one.  Normally I think this is better suited
> for dev_read_sysfs(), which has this perm already.  But since sysfs is
> so highly linked, I suppose it could make sense.  What prompted this?

Well i needed an interface that does not provide access to read files
but does provides access to read lnk_files (for listing sysfs).

I needed it for my kismet policy:

> dev_list_sysfs(kismet_servers)
> allow kismet_servers sysfs_t:lnk_file read;

>> ---
>> :100644 100644 fe31e1f... 83c4a2a... M	policy/modules/kernel/devices.if
>>  policy/modules/kernel/devices.if |    1 +
>>  1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> diff --git a/policy/modules/kernel/devices.if b/policy/modules/kernel/devices.if
>> index fe31e1f..83c4a2a 100644
>> --- a/policy/modules/kernel/devices.if
>> +++ b/policy/modules/kernel/devices.if
>> @@ -3322,6 +3322,7 @@ interface(`dev_list_sysfs',`
>>  	')
>>  
>>  	list_dirs_pattern($1, sysfs_t, sysfs_t)
>> +	allow $1 sysfs_t:lnk_file read_lnk_file_perms;
>>  ')
>>  
>>  ########################################
>> _______________________________________________
>> refpolicy mailing list
>> refpolicy at oss.tresys.com
>> http://oss.tresys.com/mailman/listinfo/refpolicy
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20100304/3a3fa11e/attachment.bin