Question about FUSE mount points and multiple user accounts - General Questions and Answers

I have an old lg pad 7 running cyanogen 12 that I use to mess around. I have two user accounts; both have root through SuperSu.
I recently discovered that even though both user storage directory mount points are accessible in terminal from both user accounts, this is no longer the case after running su due to the FUSE kernel module.
What I don't understand is that only emulated/0 (the primary user directory) is available with su no matter what account I use to run the terminal. In other words, when I run su from the terminal in the secondary user account, emulated/11 disappears as though I am still using the primary account.
I assume this is a quirk of android multiuser as it was never really intended to be used like this. I'm still curious about what's actually going on and if there is a way to override it. If anyone could explain the issue in greater detail it would definitely be appreciated.

Related

[Q] SSHFS... almost got it working...

I have SSHFS working from a Debian chroot. I have a SGS2 (SGH-i777) with CyanogenMod 9 (2012-06-12 nightly), and everything is working as the root user. I can read the SSHFS mount and the files it contains. My problem is that a normal, non root user cannot read the SSHFS mount. The UID/GID of the mount is 1000/1000, which is the UID/GID of the user that owns the source of the mount (my primary workstation user).
I'm trying to use KeePassDroid to read my KeePass database in place, so any changes I make get immediately reflected in my master file, no need to replicate the file. If I could grant KeePassDroid sudo privileges, I think that would be good enough for me. But I'm stuck. I don't know enough about how users are managed on Android, and I don't know how to give superuser privileges to an arbitrary application (it doesn't appear that the Superuser app that shipped with my root ROM allows for that). Any ideas?
SSHFS... almost got it working... a little closer now....
I've finally gotten a chance to look at this further. It looks like sshfs (the mount utility) has the capability of using an arbitrary UID for the owner of the mount. So, I looked in /data/system/packages.list to determine the UID of the KeePassDroid application. Seems the UID for that app is 10079 on my system. But that doesn't work, because if I log into a shell as that user ("su - 10079"), the keepass directory doesn't even show up in an ls directory listing. I've also tried 10080, which is apparently the UID of the OpenIntents file browser used by KeePassDroid to select the KeePass database. It obviously didn't work.
My next try will be to set the entire chroot to be owned by the 10079 user. I'll post back here if I find success.
[SOLVED]SSFS... got it working...
I finally got it to work, had to pass the -o allow_other option to sshfs, and now my KeePassDroid app can read my database. Next task is to have it load the chroot and sundry stuff automatically, so I have access to my KeePass database wherever I'm at.
Hopefully this information will be useful to the next schmo who tries this. I can already see that this thread shows up on Google.

How can we get device encryption to work?

At least one user would like to be able to encrypt their phone's filesystem.
I know that Android 3.0 and later have native encryption.
Has anyone successfully used it, or knows what needs to be done to enable it?
jeffsf said:
At least one user would like to be able to encrypt their phone's filesystem.
I know that Android 3.0 and later have native encryption.
Has anyone successfully used it, or knows what needs to be done to enable it?
Click to expand...
Click to collapse
Here are some research results from me:
NATIVE ENCRYPTION.
The native encryption works as specified here: http://source.android.com/tech/encryption/android_crypto_implementation.html
It will not work on AOKP because "cryptfs enablecrypto inplace" command will not find which device is /data . I went through some source code, and couldn't really find how this device is defined. I think, there is supposed to be an fstab somewhere which would have MF_CRYPT flag on that filesystem, but I could not find it. Maybe someone more fluent in kernel code could go through http://mirror.yongbok.net/pub/linux/android/repository/system/core/fs_mgr/fs_mgr.c (search for MF_CRYPT) and figure out. It might be as easy as to define a proper mount string in init.
EncFS ENCRYPTION
I found that EncFS will provide a reasonably working encryption. It is possible to encrypt storage per-application by encrypting /data/data/application folder, and if permissions are set right, it will run.
EncFS also allows timeout and external app to feed the password. It could be quite useful if you want folders to self-unmount, and so that you could provide some sort of a quick-unlock feature (such as: long password on boot, then allow short PIN or pattern lock to "remember" the long password). I am not sure at this time how to use this feature, because it must be a console program with GUI access, and I have no clue how to write one.
Another benefits of EncFS is that it would let selectively encrypt folders on a SD card. For example: you could keep all the music non-encrypted so that phone battery does not drain when you listen to music, but encrypt DCIM folder, so that all the photos are secure.
Just a FYI: Here is a patch to allow you to shrink the filesystem, so native encryption can work again after performing a recovery wipe.

Attaining root on Crystalview (Wondermedia) NB4-3/5788

Believe it or not, this netbook comes already rooted, but how to access it is hidden. The original adventure is posted below if you're interested,but I'll put the tl;dr up top.
You'll need to side load the app USB Debug by tatibana. This will shortcut to the hidden developer options. Slide the developer options on. You may or may not need to reboot, I was too focused on USB Debug to notice the SuperUser Options... The default is Always Deny. Set to Always Allow, then you can replace with your choice su manager (I installed Chainfire's SuperSU).
That's it. The rest below is my original posts up to this point, including getting a Linux working prior to figuring out root. Enjoy the read.
Edit 2: You can pick up new posts from this point by going directly to post #11.
Original Post:
---
Okay, this one is a bit puzzling and I haven't found any good info in searches. This is an Android netbook with Jellybean. Pointer control is a single point touch pad which makes zooming out on several apps impossible; I wish to attain root so I can install desktop Linux in parallel and use some desktop apps in place of some Android apps. I know I could use something like qemu but I'd rather install root and use arm binaries than take a performance hit using non-root methods.
This netbook comes with an installed su binary and busybox 1.19.4 but trying to invoke su results in
su: uid 10084 not allowed to su
Settings is also a bit crippled; no Developer Options section means no option to invoke USB Debugging. Anyone have any good ideas?
---
Sent from my C5155 using XDA Free mobile app
addendum
There also is no physical volume or photo buttons, and no obvious way to get into fastboot mode. My guess is that the original OS image was made in root mode, then the CV dev created a default user with almost no permissions, then backed it out effectively locking it out of root forever. I have also discovered that the busybox doesn't have access to the network as this user 10084, negating half its usability. No Play Store either (using Amazon instead), though I can (and have) install to my phone and copy to this if necessary.
This has a cool little form factor and I think has so much potential for a cheap device if I could just bust this major barrier. Does anyone know any sh or setuid tricks that might fake this thing into a root mode, or at least manage to give me enough permissions to edit /system files?
system seems to be owned by user 1003 and group 120, if that helps.
---
Mmmmmm, tasty foot...
So apparently this is normal behavior for the stock android su (see guys, I'm learning >P ); only the user shell (and root) can use su. This thing using a shared uid for apps might or might not have an effect, don't know yet. The normal way around it is to adb shell and su in, then overwrite with a custom su binary such as ChainsDD. I don't know if I have that option since there's no USB Debugging option, and I'm too tired to find out tonight. I will update this adventure later.
USB failed, but not anything to do with adb, didn't even get that far. The netbook failed to even register to the desktop (Linux)... lsusb didn't show anything. I don't know if it's a cable thing (tried direct A-A patch and the MiniUSB charge port- charge port predictably didn't support data and neither standard port showed any reaction) or a hardware limitation.
I also took a crack at adb over wifi but as usual it was the catch 22 of needing root to invoke adbd into tcpip to attain root.
Still open to suggestions... please?
---
Sent from my C5155 using XDA Free mobile app
Developer Options?
This is driving me up a new wall. Based on what I have been reading all day, Developer Options are a core function and cannot be removed, only hidden. This thing has not been giving me much confidence in that statement, however. I have been through the settings over and over again with a fine tooth comb and the whole thing eludes me.
This is Android 4.1.1. The 4.2+ trick (7 clicks on Build Number) doesn't work, and it's not in the App settings either, nor is there any sections renamed "Advanced" or the like. It may not be an end-all but I feel it would at least be a step in the right direction. I might be able to use an exploit such as Poot or Framearoot, which are currently ineffective.
I also haven't had any luck with getting into a recovery boot mode, not sure it's possible with this keyboard (I suspect it's soft driven; inactive until the kernel and modules are loaded). This seems to be just one shut down after another. I need more ideas, pointers, whatever. Don't forget, it can also help the next sap stuck with this model...
I decided to not lose sight of my original reasoning and move forward anyway with an app that claims to install Linux without root. I installed Gnuroot Wheezy which taught me some more f'd up things about this netbook but it at least in concept is working. What more things I have learned...
One of the issues with running Linux without root is the inability to use the external SD-card, at least native, because you can't mount an external partition/file that hasn't already been set up in the mount scripts outside of userspace. Gnuroot uses a chroot off the secure asec in /data. With about 3G user space available on this netbook, you'd think that wouldn't be a problem... but it is, because of another setup issue with this netbook...
See, while the external SD card does mount to /sdcard,/mnt/sdcard, that is NOT where Android app setup calls SDcard... there is a so called internal SDcard that is really a fake vfat via fuse mount off /data mounted to /mnt/local. This means it does no good to move my plethora of other apps to the "SD Card," actually, it makes the problem worse on this device. I imagine it was done so you could swap SD cards without affecting your apps, good move for flexibility but poor for expandability.
For those who would try it, that's also a big hint for getting it working. This device does not have access to the Play market*, so you will have to move helper apps from another Android device over. Don't bother with 3rd party repositories, you will not get everything you need. The biggest issue is the WheezyX obb file. It on install ONLY from the Play store will be located in /sdcard/Android/obb/champion.gnuroot.wheezyx/main.2.champion.gnuroot.wheezyx.obb , on this netbook the file must be moved to /mnt/local/Android/obb/champion.gnuroot.wheezyx or it will not be recognized, and because of the play store issue, can't be downloaded and gnuroot will exit with error.
Anyway, so now WheezyX is actually running and I am attempting to install an Openbox/LXDE desktop... the problem I am hitting now is the space limitation... It said it needed about 330 MB space and I had 360MB available on start... I'm now about 1/4 through and the netbook has come to a dead crawl due to... yep, very little space left (about 55 MB free on /data)... WTF! I feel like I am just not meant to win at like anything...
---
*Edit: Once rooted, the play store can be installed to the system partition and does work pretty good.
---
Sent from my C5155 using XDA Free mobile app
Some success with Linux
Well, it took quite a bit of monkeying and persistence but I do have desktop Linux running via the above described method. I found Synaptic was useful for finding packages but as the GNURoot author warned, for the love of all that's holy, use apt-get to actually install the packages. It seems trying to install a desktop environment via Synaptic totally overthrew the system. Also try installing only a few packages at a time and clean up after each one, especially where space is a premium.
What's left now is experimenting with vnc viewers a/o X11 environments. I'm presently using PocketCloud but it doesn't seem to like this keyboard (right shift = 6, no down arrow, Ctrl is sticky- forget combo keys; at least the included soft-keyboard does work, just a productivity killer) and getting a right mouse click is almost impossible, so I want to see if I can do better.
The environment is OpenBox with lxpanel and the background is set with qiv. I am confident now that providing space wasn't such an issue I could run pretty much any basic Linux program I want. I have not tested audio and I already know just being vncserver that motion video is a bad idea; this was mostly proof of concept until I can open up some space. I may now see how far I can take this (e.g. link large trees to the SD card, such as bin directories; since it's already running fake-root, I'm not too worried about user permissions. I may also experiment with fuse).
Edit:
This does not mean I don't still want to get a true root. If nothing else, even if I can't take Linux off the internal storage, root will allow me to force Android apps on to the external SD; either solves the current space issue and thus is still desirable. I'm just not as stuck in the mud now. Ideas still very much appreciated.
Done and done.
Just a quick update to say the project isn't dead, just dormant. I have successfully turned on USB debugging thanks to a shortcut app called "USB Debug" by Tatibana. Thank you
---
Sent from my C5155 using XDA Free mobile app
Framaroot, Universal Androot, and Poot have all failed.
:banghead:
Have yet to see if physical USB will now work... I don't exactly live alone.
---
Sent from my C5155 using XDA Free mobile app
SUCCESS!!!!!
IDFBT! I must have not been paying enough attention before or something, or maybe it was one of the half dozen greyed out options before... not sure, but after I was again unable to connect via direct USB, I decided to double check the developer options to make sure noting was reset by the last reboot.... and there in bright white last in the top section... Superuser Options (set to Always Deny)! I set it to Ask and tested, but it promptly rebooted as soon as I tried to su, and again on that boot, so I had to set to Always Allow. Amazon doesn't have SuperSU and last I knew ChainsDD Superuser is still adrift in the doldrums, so I'll have to sideload (as usual), but, I just wanted to share. This netbook does come rooted, you just need to turn on the hidden developer options, reboot, and go back and allow SuperUser.
Will report more as I progress. Banzai!!!
Adventures in Linux land
Well, I had mentioned before how space was an issue. Thanks in part to Link2SD, I managed to curb that problem.
Problem still though was my base graphical Linux install was taking 1G of my /data space. Since I made 2G available on the Link2SD ext4 (/data/sdext2) partition, I found I had about 1.3G available after moving most apps over, I decided I'd try a manual data move. I was slow with this since I didn't know how Link2SD or the system was going to handle it. That turned out to be a good thing.
When using Link2SD, one thing that should be obvious is to never move essential apps off the internal storage. These would be things like Link2SD itself, a Terminal emulator, and your superuser manager (e.g. SuperSU); basically, things you absolutely cannot lose access to even temporarily.
Okay, so, to test the behavior, I went into the emulator..
su
cd /data/sdext2
mkdir Linux
That's all. I then did a normal power off and restart. When rebooting, an "Android is Updating..." box came up and went away in a few seconds. The launcher came up and I waited for everything to load normally. Then I started getting a rash of "App is not installed" messages... uh oh. The only reason this turned out to not be a big deal is Link2SD and SuperSU were still on internal storage, and Link2SD is designed to deal with this problem. I simply launched Link2SD, clicked the tab bar on the upper left, and selected "Relink all application files," after which it requested a reboot, and I complied.
With a semi-disaster averted, I went back into /data/sdext2 to see if the Linux directory was still there. Hallelujah it was. Next was finding the GNURoot wheezyx root. This turned out to be fairly easy:
/data/data/champion.gnuroot/app_install/roots/wheezyx . I decided for potential future expansion to move the whole roots directory. Being cautious as I try, I do a copy.
su
cd /data/data/champion.gnuroot/app_install
cp -a roots /data/sdext2/Linux/
(... go make a sammich ...)
rm -R roots
(... go make and eat dinner ...)
ln -s /data/sdext2/Linux/roots roots
This appeared to work at first, until I tried to install something (abiword). I discovered that the permissions were not copied to the lib directories (android security quirk?). This would probably not be an issue if this were a true root install but being a fake root app install, it effectively prevented the installation of libraries. This was fixed simply by doing a chown and chmod on the lib directories.
Contined from above:
cd roots/wheezyx
chown 10102.10102 lib
chmod 771 lib
chown 10102.10102 usr/lib
chmod 771 usr/lib
*note: the app id number may be different on your copy. This will be fairly obvious with a simple ls -lh .
After that, the install completed and this thing is running pretty good. I am now considering this a complete success. While technically solved, I'll keep this thread open for questions or updates (for as long as the mods don't mind).
---
Sent from my C5155 using XDA Free mobile app
Screencap op
Assuming the uploads work this time, attached are some screencaps. Enjoy.

[Q] Debian chroot on phone/networking issue

Hello XDA Developers, I have a Debian subsystem of sorts on my phone which is created by an application called Lil' Debi. For those of you unfamiliar with it, it essentially creates a Debian install on an .iso that can be mounted onto the disk. Once mounted, a user can access a shell to interact with this Debian subsystem by running /debian/shell as root, which will chroot to its own directory system separate system accessible from the Android Terminal.
Within this Debian subsystem I have created a non-root user account for the purpose of running a few networking applications that if compromised for some reason, won't give the attacker root privileges to break everything on my phone. There's only one small problem with this setup: I can't access the internet from a non-root account.
Both my terminal emulator and Lil' Debi have full network access, even when not run as root. I am curious then, why a non-root user account should have an incapability of accessing the network. A sample of wget on my phone using Google's IP address (I use the IP address because it cannot do DNS lookup obviously) gives a Permission Denied error. At the current moment I am not sure whether this problem lies with Android or with Debian. Does the user need to be explicitly granted permissions to use the network through Debian, or is the application somehow only able to access the network if it's root?
Additional information: The ROM used is PAC ROM, so you can assume any settings changes that could be made from Cyanogenmod or Paranoid Android can be made if necessary. The phone itself is a Oneplus One. No I don't have invites, so don't bother asking.
Opinions on the matter?
Also, on an unrelated note, g++ will only run under root. If I launch it as a non-root user, it will tell me that execvp failed because cc1plus doesn't exist. Why?
Thread's fallen onto the third page, so I'm going to bump.
One day has passed, and no help offered. Bump again.
Another bump. I thought XDA was supposed to be the most knowledgeable forum on Android.
Daily bump until this problem is solved...
Still bumping...
I hope people aren't just looking at the number of replies and assuming it's resolved...
Bumping again. At least 100 people have seen this thread, and not a single one has anything to say.
Bump again. It's now been a week since I asked this question.
Bump.

Why isn't there Linux style root on Android?

This is something I have been wondering for a while and after searching the forums and Google I have not been able to find a clear answer. As a long time Linux user the idea of running your system as root all the time is appalling. It is a huge security risk. But for some reason that is really the only way to gain root access on an Android device (as far as i am aware). Apps like SuperSU allow you to pick the apps that are allowed to run as root, but there is no password or verification that the entity approving the access actually has the authority to do so. I hear all the time that rooting your phone is a trade-off between customizability and security, but every Linux system has a root user and it is incredibly secure when properly administered. What is the reason for the difference?
From what I have read, it sounds like part of the issue has to do with Android handling users differently. I would love to be able to maintain a more limited root function on my devices. Thanks.
funkbuqet said:
This is something I have been wondering for a while and after searching the forums and Google I have not been able to find a clear answer. As a long time Linux user the idea of running your system as root all the time is appalling. It is a huge security risk. But for some reason that is really the only way to gain root access on an Android device (as far as i am aware). Apps like SuperSU allow you to pick the apps that are allowed to run as root, but there is no password or verification that the entity approving the access actually has the authority to do so. I hear all the time that rooting your phone is a trade-off between customizability and security, but every Linux system has a root user and it is incredibly secure when properly administered. What is the reason for the difference?
From what I have read, it sounds like part of the issue has to do with Android handling users differently. I would love to be able to maintain a more limited root function on my devices. Thanks.
Click to expand...
Click to collapse
You can set a passcode with SuperSU....
Thanks for the reply. That is good to know. Does that really fill the security gap though? I guess if I set My non-background root permissions to expire every 15 minutes that does help for apps that do not need to run as root in the background.
I am more referring to the distinction between regular user land and the root user. Titanium Backup for example; If I want it to be able to run a full backup (including system apps and settings) of my phone every night I have to give it permanent root permissions. That root permission applies to both the automatic process and anything that I as a user (or any entity that can get control of TB) to act as root as well. Ideally there would be 2 separate instances of the program; the back-up process (a daemon perhaps) initiated by the root user and a second available in regular user space. This sort of thing is common on Linux systems.
My knowledge of Android is not particularly deep. I cannot tell if there is actually a separate root user or how user/group permissions work. It seems that the Android framework is designed around the user not having root access. Which is a bit confusing for an OS that prides itself on customization and "Be together not the same". I can't imagine buying a desktop PC that didn't allow me to have system level (root) access. Why should it be any different on a mobile device?

Categories

Resources