Hello,
Dominick Grift wrote:
>> ########################################
>> ## <summary>
>> ## ? ?Create file, dir, links of specified type in
>> ## ?kde_shared_home_t dirs with type transition
>> ## </summary>
>> ## <param name="domain">
>> ## ? ?<summary>
>> ## ? ?Domain allowed access
>> ## ? ?</summary>
>> ## </param>
>> ## <param name="private type">
>> ## ? ?<summary>
>> ## ? ?Private type of created object
>> ## ? ?</summary>
>> ## </param>
>> #
>> interface(`files_kde_home_filetrans',`
>> ? ? ? gen_require(`
>> ? ? ? ? ? ? ? type kde_shared_home_t;
>> ? ? ? ')
>>
>> ? ? ? ? ?type_transition $1 kde_shared_home_t:{ file lnk_file sock_file dir } $2;
>>
>> ')
> This is a bad idea. processes should not type transition to type that they do not own.
> use manage_files_pattern instead.
>>
This is because of konqueror config files in directory
~/.kde/share/config/. The directory has type kde_shared_home_t and
config files konqueror_home_t. Now, when theese files are rewritten,
they switch to directory type kde_shared_home_t without this type
transition. This is unwanted, as they should hold their own type
konqueror_home_t. I tried to keep the functionality with
manage_files_pattern, but I was unsuccecful. When I think of it more,
I don't agree that process is type transitioning to type that it
doesn't own. As it is called by process konqueror_t and the files
switch to type konqueror_home_t. But it can probably be called with
whatever type one wants, though it is not in my policy, so I think it
is not an issue, or is it?
Thanks for your time,
Ondrej Vadinsky
--
"Don't it always seem to go
That you don't know what you've got
Till it's gone."
(Joni Mitchell)
On Thu, Sep 10, 2009 at 03:12:59PM +0200, Nicky 726 wrote:
> Hello,
>
> Dominick Grift wrote:
> >> ########################################
> >> ## <summary>
> >> ## ? ?Create file, dir, links of specified type in
> >> ## ?kde_shared_home_t dirs with type transition
> >> ## </summary>
> >> ## <param name="domain">
> >> ## ? ?<summary>
> >> ## ? ?Domain allowed access
> >> ## ? ?</summary>
> >> ## </param>
> >> ## <param name="private type">
> >> ## ? ?<summary>
> >> ## ? ?Private type of created object
> >> ## ? ?</summary>
> >> ## </param>
> >> #
> >> interface(`files_kde_home_filetrans',`
> >> ? ? ? gen_require(`
> >> ? ? ? ? ? ? ? type kde_shared_home_t;
> >> ? ? ? ')
> >>
> >> ? ? ? ? ?type_transition $1 kde_shared_home_t:{ file lnk_file sock_file dir } $2;
> >>
> >> ')
> > This is a bad idea. processes should not type transition to type that they do not own.
> > use manage_files_pattern instead.
> >>
>
> This is because of konqueror config files in directory
> ~/.kde/share/config/. The directory has type kde_shared_home_t and
> config files konqueror_home_t. Now, when theese files are rewritten,
> they switch to directory type kde_shared_home_t without this type
> transition. This is unwanted, as they should hold their own type
> konqueror_home_t. I tried to keep the functionality with
> manage_files_pattern, but I was unsuccecful. When I think of it more,
> I don't agree that process is type transitioning to type that it
> doesn't own. As it is called by process konqueror_t and the files
> switch to type konqueror_home_t. But it can probably be called with
> whatever type one wants, though it is not in my policy, so I think it
> is not an issue, or is it?
>
The location is owned by kde (its called .kde) and konqueror needs to manage files there so i really think manage_file_pattern is better
The name of the type kde_shared_home_t also suggest that. it is a location with object that kde shares with other domains for example konqueror. kde owns the (shared) location and konqueror manages stuff there.
my $0.2 , i might be wrong about it.
> Thanks for your time,
> Ondrej Vadinsky
>
> --
> "Don't it always seem to go
> That you don't know what you've got
> Till it's gone."
>
> (Joni Mitchell)
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
-------------- 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/20090910/f93def20/attachment.bin