[ZTE ZMAX Guides, News, & Discussion] sketchscarz:
I found something big:

The fuse mount has an API and

A) The mount owner could gain elevated privileges by either:

1) creating a filesystem containing a device file, then opening

this device

2) creating a filesystem containing a suid or sgid application,

then executing this application

The solution is not to allow opening device files and ignore

setuid and setgid bits when executing programs. To ensure this

fusermount always adds "nosuid" and "nodev" to the mount options

for non-privileged mounts.

B) If another user is accessing files or directories in the

filesystem, the filesystem daemon serving requests can record the

exact sequence and timing of operations performed. This

information is otherwise inaccessible to the mount owner, so this

counts as an information leak.

The solution to this problem will be presented in point 2) of C).

C) There are several ways in which the mount owner can induce

undesired behavior in other users' processes, such as:

1) mounting a filesystem over a file or directory which the mount

owner could otherwise not be able to modify (or could only

make limited modifications).

This is solved in fusermount, by checking the access

permissions on the mountpoint and only allowing the mount if

the mount owner can do unlimited modification (has write

access to the mountpoint, and mountpoint is not a "sticky"

directory)

2) Even if 1) is solved the mount owner can change the behavior

of other users' processes.

i) It can slow down or indefinitely delay the execution of a

filesystem operation creating a DoS against the user or the

whole system. For example a suid application locking a

system file, and then accessing a file on the mount owner's

filesystem could be stopped, and thus causing the system

file to be locked forever.

ii) It can present files or directories of unlimited length, or

directory structures of unlimited depth, possibly causing a

system process to eat up diskspace, memory or other

resources, again causing DoS.

The solution to this as well as B) is not to allow processes

to access the filesystem, which could otherwise not be

monitored or manipulated by the mount owner. Since if the

mount owner can ptrace a process, it can do all of the above

without using a FUSE mount, the same criteria as used in

ptrace can be used to check if a process is allowed to access

the filesystem or not.

Note that the ptrace check is not strictly necessary to

prevent B/2/i, it is enough to check if mount owner has enough

privilege to send signal to the process accessing the

filesystem, since SIGSTOP can be used to get a similar effect

---------- Post added at 06:42 AM ---------- Previous post was at 06:31 AM ----------

mount | grep msm_sdcc

/dev/block/platform/msm_sdcc.1/by-name/system /system ext4 ro,seclabel,relatime,

data=ordered 0 0

/dev/block/platform/msm_sdcc.1/by-name/userdata /data ext4 rw,seclabel,nosuid,no

dev,relatime,noauto_da_alloc,resuid=1000,resgid=9997,data=ordered 0 0

/dev/block/platform/msm_sdcc.1/by-name/cache /cache ext4 rw,seclabel,nosuid,node

v,relatime,data=ordered 0 0

/dev/block/platform/msm_sdcc.1/by-name/persist /persist ext4 rw,seclabel,nosuid,

nodev,relatime,data=ordered 0 0

/dev/block/platform/msm_sdcc.1/by-name/modem /firmware vfat ro,relatime,uid=1000

,gid=1000,fmask=0337,dmask=0227,codepage=cp437,iocharset=iso8859-1,shortname=low

er,errors=remount-ro 0 0

shell@draconis:/ $

As can seen from the above output, the mount command provides the mount point, file system type, and whether the partition is read only (ro), or read-write (rw). Looks like we can write on a couple. lets write su lol

---------- Post added at 06:47 AM ---------- Previous post was at 06:42 AM ----------

Files can be shared to other devices, while the Android device remains active. Thus, you have full use of your Android device, while transferring files. For example, you could use your phone as a media player, while talking on the phone, using GPS, or taking pictures. Instead of using USB mounts, files are transferred using MTP (Multimedia Transfer Protocol).

FUSE allows a single partition for data and user files, as only selected files are shared via FUSE.

The data partition can be formatted with any file system, as FUSE hides the original file system. Thus eliminating the need to support FAT32 for the sake of file transfer. The standard is to format the data partition with the EXT4 file system.

---------- Post added at 06:48 AM ---------- Previous post was at 06:47 AM ----------

There are a number of disadvantages to FUSE:

The use of MTP requires a MTP compliant application on your PC. This should not be a problem with Microsoft Windows or MAC, but does present some challenges to a Linux user. The article "Transferring Files via USB - Understanding MTP and PTP" below discusses file transfer in more detail.

There appears to be a 1024 file limit to open files. I need to do some kernel research to find the parameter that sets this limit.

http://www.all-things-android.com/content/transferring-files-usb-understanding-mtp-and-ptp

---------- Post added at 06:49 AM ---------- Previous post was at 06:48 AM ----------

There is MTP file transfer boys n gals

---------- Post added at 06:52 AM ---------- Previous post was at 06:49 AM ----------

It looks as if our MTP mode is our FUSE partition guys.. read the writable blocks and lets xfer the su. I have superuser and busybox already installed. This su just needs to be executed in the correct parameter. Get the MTP compliant transfer tool, and I beleive we'll have to create the dirs and send them through MTP. not sure.

---------- Post added at 06:56 AM ---------- Previous post was at 06:52 AM ----------

In the article Review of Android Partition Layout, we looked at the flash memory partition scheme for Android. With USB mass storage, a single partition was mounted as an external USB drive. Essentially, the flash memory in a smartphone was treated like as USB flash drive. While this approach was familiar to the user, it had serious limitations, as follows:

Only one operating system can mount a device as a direct storage drive. While this is not an issue with USB memory sticks, it is an issue with a smartphone. For a PC to mount a partition as USM, the phone had to unmount the partition. Consequently, the information on that partition is no longer available to the phone. The design goal of Android was that the mobile device should always have access to a partition. In other words, Android needs to share data on its drive much like you share data on your PC's disk drive.

To share information, the operating system requires a separate protocol. For file sharing, the common protocols are NFS and CIFS, but they are not common protocols in the consumer electronics industry. They require far too much software overhead to be a practical solution for devices such as TVs and music players. PTP was already a standard protocol for cameras, and MTP was a standard protocol used by multimedia devices. It was a matter of going with the industry flow.

USM meant that the partition had to use the FAT format, as this is the standard for USB memory sticks. MTP and PTP mean that the Android device is free to use any file system format for the shared data. Android moved to EXT4 as a standard format for many partitions, including the data partition.

The ability to use a different file system format meant that the application partition and data partition could be merged. This merger ended the battle between space for applications versus space for data. Instead of the split being determined by the mobile device designers, the user makes the decision of how to use storage space.

http://www.all-things-android.com/content/review-android-partition-layout

---------- Post added at 06:59 AM ---------- Previous post was at 06:56 AM ----------

There you go guys. A proposed root method. The MTP needs to be accessed. MTP means Media Transfer protocol. Just gotta find the interface tool for Windows. Its up there in the links I provided.