Are you using the screencap binary? Are you calling it via dumpstate or another script or an app....

On 08/06/2013 09:04 AM, Janosch Maier wrote:
When trying to create a screenshot I get the following messages:

type=1400 msg=audit(1375793698.910:17): avc:  denied  { getattr } for
pid=1893 comm="sdcard" path="/data/media" dev=mmcblk0p12 ino=316369
scontext=u:r:sdcardd:s0 tcontext=u:object_r:unlabeled:s0 tclass=dir
type=1400 msg=audit(1375793700.785:18): avc:  denied  { write } for
pid=1880 comm="sdcard" name="Screenshots" dev=mmcblk0p12 ino=316402
scontext=u:r:sdcardd:s0 tcontext=u:object_r:unlabeled:s0 tclass=dir
type=1400 msg=audit(1375793700.785:19): avc:  denied  { add_name } for
pid=1880 comm="sdcard" name="Screenshot_2013-08-06-14-55-00.png"
scontext=u:r:sdcardd:s0 tcontext=u:object_r:unlabeled:s0 tclass=dir
type=1400 msg=audit(1375793700.785:20): avc:  denied  { create } for
pid=1880 comm="sdcard" name="Screenshot_2013-08-06-14-55-00.png"
scontext=u:r:sdcardd:s0 tcontext=u:object_r:unlabeled:s0 tclass=file
type=1400 msg=audit(1375793700.785:21): avc:  denied  { read write } for
  pid=1893 comm="sdcard" name="Screenshot_2013-08-06-14-55-00.png"
dev=mmcblk0p12 ino=316416 scontext=u:r:sdcardd:s0
tcontext=u:object_r:unlabeled:s0 tclass=file
type=1400 msg=audit(1375793700.785:22): avc:  denied  { open } for
pid=1893 comm="sdcard" name="Screenshot_2013-08-06-14-55-00.png"
dev=mmcblk0p12 ino=316416 scontext=u:r:sdcardd:s0
tcontext=u:object_r:unlabeled:s0 tclass=file

However the created screenshot in the /sdcard/Pictures/Screenshots
folder will get the correct labels:
-rw-rw-r-- root     sdcard_rw          u:object_r:sdcard_internal:s0
Screenshot_2013-08-06-14-55-00.png

I am trying to allow capturing screenshots.

Am 02.08.2013 14:51, schrieb Stephen Smalley:
On 08/02/2013 05:35 AM, Janosch Maier wrote:
Some more followup for the /data/media issue is needed:

The fuse labeling works, i think. The files in /sdcard or /mnt/sdcard
look fine:
drwxrwxr-x root     sdcard_rw          u:object_r:sdcard_internal:s0 Alarms

But the files in /data/media/0 which is the original location of the
files does not:
drwxrwxr-x media_rw media_rw          u:object_r:unlabeled:s0 Alarms

The sdcard service adresses the mounting:
# create virtual SD card at /mnt/sdcard, based on the /data/media directory
# daemon will drop to user/group system/media_rw after initializing
# underlying files in /data/media wil be created with user and group
media_rw (1023)
service sdcard /system/bin/sdcard /data/media /mnt/shell/emulated 1023 1023
     class late_start

However, when working on the system, the access to the files is done via
/data/media and will fail in enforcinge mode.
On our devices, /data/media is labeled with system_data_file,
shell@manta/ # cd /data/media
shell@manta:/data/media # ls -Z
drwxrwx--- media_rw media_rw          u:object_r:system_data_file:s0 0
drwxrwxr-x media_rw media_rw          u:object_r:system_data_file:s0 legacy
drwxrwx--- media_rw media_rw          u:object_r:system_data_file:s0 obb

While /data/media provides the underlying storage, I don't believe it
should be accessible in the same way as the fuse mount.  Note that the
DAC ownerships and modes are different as well.  Thus we don't want the
same type on it.

I think if you use the correct APIs for accessing external storage, then
you will go through the fuse mount interface and thus not have any
problems with permissions.





--
This message was distributed to subscribers of the seandroid-list mailing list.
If you no longer wish to subscribe, send mail to [email protected] with
the words "unsubscribe seandroid-list" without quotes as the message.


--
This message was distributed to subscribers of the seandroid-list mailing list.
If you no longer wish to subscribe, send mail to [email protected] with
the words "unsubscribe seandroid-list" without quotes as the message.

Reply via email to