On 10/26/2014 02:20 PM, Dinesh Garg wrote:
> Hi Guys,
> I have two processes, say P1 & P2. Both access data under /data/data/common
> ( say label L1).
How is /data/data/common initially created and labeled with L1? Is it
created via a mkdir /data/data/common by init.<board>.rc? Did you
specify u:object_r:L1:s0 as its context in file_contexts? That is the
preferred way to set it up with its own type.
> I have given rw_file_perms (/data/data/common) & r_dir_perms(/data/data) to
> domain D1 which P1 & P2 belongs to.
rw_file_perms only allows reading and writing existing files with a
given type, not creating or unlinking them (see the definitions in
global_macros). r_dir_perms only allows reading and searching the
directory, not adding or removing entries. So what you describe above
is insufficient to allow deleting /data/data/common or its files.
Please show your actual allow rules, not just this summary form, as it
is clearly incomplete and does not match the behavior you describe.
> When P1 tries to delete /data/data/common, it succeed but can't create
> directory again i.e. /data/data/common.
If your description of your allow rules above is accurate, then
processes running in D1 should neither be able to delete nor create
/data/data/common or its files. They would only be able to read and
write existing files under /data/data/common. In addition to the allow
rules, please show any avc: denied messages that you received for D1
and/or L1 in your dmesg or logcat output. Also it would be good to
confirm that P1 and P2 are both running in D1 (via ps -Z) and that
/data/data/common is labeled with L1 (via ls -Zd /data/data/common).
However, the preferred approach is to pre-create the /data/data/common
directory via init.<board>.rc and never delete the directory itself,
just files (and if appropriate, subdirectories) within it. Otherwise,
your domain D1 will need at least write, remove_name, and add_name
permissions to system_data_file:dir in order to remove and add entries
for /data/data. D1 would also need rmdir and create to L1:dir to remove
and re-create /data/data/common. And you would need a type_transition
D1 system_data_file:dir L1; rule or a setfscreatecon("u:object_r:L1:s0")
call prior to calling mkdir() by P1 and P2 in order to assign
/data/data/common L1 each time they re-create it (the latter is what
init is doing when your init.<board>.rc file calls mkdir
/data/data/common; it looks up the correct context from file_contexts
and then calls setfscreatecon() prior to creating the directory).
Far simpler and more secure if P1 and P2 only create and delete files
under /data/data/common, not the top-level /data/data/common directory
itself, and leave the creation and labeling of the top-level
/data/data/common directory to init.
> When P2 tries to delete /data/data/common, it fails but it can delete all
> of its content i.e. /data/data/common/f1.
I wouldn't expect it to be allowed to delete the directory or its files
from your description of the rules. You didn't say you allowed unlink
to anything, nor rmdir.
> Does anything explains this anomaly considering P1 & P2 belongs to same
> domain ?
If P1 and P2 are truly running in the same domain, then the only reason
for one of them to be able to delete /data/data/common and the other not
would be something other than SELinux, e.g. a DAC denial or some other
error. What errno did P1 and P2 get when the create or delete failed,
and was there an avc: denied message or not?
_______________________________________________
Seandroid-list mailing list
[email protected]
To unsubscribe, send email to [email protected].
To get help, send an email containing "help" to
[email protected].
