[Q] Cyanogen: Set net.hostname at boot - Android Q&A, Help & Troubleshooting

Android 2.2 sets the default hostname to android_dfhjkahdjksf or something equally useless.
To override this in Cyanogen 6.1 you need to set the net.hostname property with setprop Eg:
# setprop net.hostname mickey
My problem is when I try to set this up at boot, something always overwrites my change with the default. I have tried putting it in my init.rc, /etc/init.d and /data/local/userinit.sh and it is always reset to default by the time the phone has booted.
Does anyone have any more ideas about how to permanently set the hostname? It would be a good option to have in cyanogenmod.

UP. I'm very interesting too.

The root filesystem is stored in the boot.img and is expanded to a ramdisk every time you reboot. For changes to be permenant, you need to extract the boot.img file, extract the kernel and ramdisk sections, modify the ramdisk image with your changes, then recombine the kernel and ramdisk to a new boot.img and reflash it. You'll probably need to do this on a linux machine that understands unix permissions and ramdisk/cpio filesystems as well as having a good knowledge of linux and unix commands. See this thread:
http://forum.xda-developers.com/showthread.php?t=551711
note: your kernel may use a different "--base 0x19200000" option when building the kernel boot image.

Is there not a way to add a correlating line to the build.prop file?
EDIT: This doesn't work - whatever is setting the net.hostname writes out after build.prop is read.
I'm looking...
I did a search in the /system/etc directory for any file doing setprop (I'm using a miui rom) and found the following script. I did the setprop for net.hostname in there and it too is being overwritten.
search command:
grep -H -r setprop /system/etc
/system/etc/init.goldfish.sh
I'm running out of ideas other than using autostart to set it after reboot.
EDIT2: doh. I think I already knew this but it dawned on me that the default net.hostname comes from concatenating the "android_id" (found in the secure database table) to the end of "android_".
So seems more likely to reset it after reboot using a script (gscript to launch it manually or use autostart to launch it automatically at the end of reboot cycle).

Property net.hostname originate from services.jar (ConnectivityServices.java):
Code:
// setup our unique device name
String id = Settings.Secure.getString(context.getContentResolver(), Settings.Secure.ANDROID_ID);
if (id != null && id.length() > 0) {
String name = new String("android_").concat(id);
SystemProperties.set("net.hostname", name);
}
Maybe CM guys would change this to add another "if /proc/sys/kernel/hostname is different than localhost, use it for net.hostname too" condition.
I'm not using CM so it is up to you guys to make a feature request.
Another approach would be to set service in init.rc that would start your net.hostname changing script on some property being set just after net.hostname is set. You could use also:
Code:
on property:net.hostname=android_blahblah
...but that wouldn't be so handy since you will have to change that line in init.rc every time you make a factory reset.

Really interesting, thx !

BlaY0 said:
Property net.hostname originate from services.jar (ConnectivityServices.java):
Code:
// setup our unique device name
String id = Settings.Secure.getString(context.getContentResolver(), Settings.Secure.ANDROID_ID);
if (id != null && id.length() > 0) {
String name = new String("android_").concat(id);
SystemProperties.set("net.hostname", name);
}
Maybe CM guys would change this to add another "if /proc/sys/kernel/hostname is different than localhost, use it for net.hostname too" condition.
I'm not using CM so it is up to you guys to make a feature request.
Another approach would be to set service in init.rc that would start your net.hostname changing script on some property being set just after net.hostname is set. You could use also:
Code:
on property:net.hostname=android_blahblah
...but that wouldn't be so handy since you will have to change that line in init.rc every time you make a factory reset.
Click to expand...
Click to collapse
Thanks a lot. I've been looking for this for the past hour or so. Traditional linux methods to set the hostname don't work... I think I'll add an option in cyanogenmod settings for this and submit it to Gerrit. Look for it to show up within the next day or two.

That's great m8! Cheers
Sent from my HTC Legend

underscores in hostnames are bad
The main thing I want to do is get rid of that underscore. Several of the places I hook up with with WiFi attempt to enter the hostname supplied during the DHCP conversation into a DNS. But underscore is illegal for this purpose.
Numbat.

Questions or Problems Should Not Be Posted in the Development Forum
Please Post in the Correct Forums
Moving to Q&A

Related

[MOD] Change WiFi hostname - for custom ROMs (Sept 23)

This is useful for identifying phones on the local networks by looking at DHCP lease tables in the routers. It doesn't make your phone appear on Windows networks, since the phone needs to broadcast NetBIOS name for that. If you want your phone to show up on Windows networks (and share files) - you need Samba server, and JimmyChingala is working on one.
ROM developers can insert the option to customize hostname using the way described below in their Spare Parts options. Feel free to do so.
[SOLUTION]
The following shell command does the job of changing WiFi hostname:
echo YOURHOSTNAME > /proc/sys/kernel/hostname
Click to expand...
Click to collapse
For the change to stay, it should be executed on each boot. And here the things start being more problematic.
For custom ROMs:
Most, if not all, custom ROMs include some user init shell script that will be executed on boot, making the solution easy.
Enter the following line in the Terminal / ADB shell:
echo "echo YOURHOSTNAME > /proc/sys/kernel/hostname" >> the_path_and_name_of_userinit_script.sh
chmod 777 the_path_and_name_of_userinit_script.sh
Click to expand...
Click to collapse
Several examples of custom ROMs and their userinit scripts:
Suggested - will work for most ROMs (creates another file in directory of autoexecuted scripts): /etc/init.d/88hostnameinit
Additional possibility for Enomther's ROM: /data/local/userinit.sh
Additional possibility for CyanogenMOD: /sd-ext/userinit.sh
For stock ROMs:
There is no autorun script for stock ROMs, so they have to be added through modifying boot.img. It's a complicated procedure, and even though guides exist for it - I suggest not to mess with it only because of the hostname. The easiest solution would be to create a script file with the line above using Gscript or other scripting solutions, and execute it after each reboot. If anyone really wishes to modify boot.img - I assume that he/she knows enough about Linux/Android since it can be relatively easily done only on Linux, can find the necessary guides with some googling (like I did), and in this case the modification is easiest to do directly in init.rc - changing "hostname localhost" to "hostname name_of_your_choice".
[ORIGINAL POST]
Hi people,
I'm not much of a dev, but I can find my way around with a bit of Google search And sorry about the links that don't link, new user's permissions don't allow me to...
Anyway, after messing with my router today I've noticed that Nexus transmits "localhost" as its host name to DHCP server, causing my DD-WRT to show it as "*". I went to Google and to my surprise, discovered that there isn't such an option in any Nexus ROM yet.
Found this: LINK_www_laslow_net_?p=501
To change your hostname on Cyanogen 5.x, add the following line to the bottom of /system/etc/init.d/01sysctl -- and make sure you make a backup of 01sysctl before editing it!
echo NEWHOSTNAME > /proc/sys/kernel/hostname
Click to expand...
Click to collapse
I tested it, and it didn't work. After booting, the file still read "localhost" in it, and the hostname on DHCP server reflected it.
But, I didn't get frustrated, connected with ADB, manually executed the command:
echo MyHostName > /proc/sys/kernel/hostname
checked that the file was overwritten, disabled WiFi, deleted DHCP lease, enabled WiFi back - and voila, I have a new hostname!
Then I went to search for hostname setting, which got me to /init.rc:
on boot
# basic network init
ifup lo
hostname localhost
domainname localdomain
Click to expand...
Click to collapse
Well, I guess that's the place. A tiny problem, though - it's in the boot image, which can't be easily modified. Thanks to the latest thread on update.zip creation I can probably do it myself, but I wanted to share the findings and ask for the correct way to implement.
There's a "dirty but functional" way of "disable WiFi - override /proc/sys/kernel/hostname - enable WiFi", and it's probably not a problem to stick it somewhere in the boot sequence, or even write an app that writes those changes to one of the boot scripts and allows configuration of host and domain names. But it's not the best way - DHCP might already give out a lease, and the new host name might not register.
And there's a correct (?) way of doing it, introducing it into init.rc. Since it's "on boot", I suppose that it runs after mounting the partitions - which means that the partitions are already accessible.
In this case, the best way would be executing a small shell script that would check for existence of, say, "/system/etc/settinghostdomainnames.rc" and create a default one if it's not there, then use "import /system/etc/settinghostdomainnames.rc" and set a manual trigger, like the guy is trying to do here:
LINK_groups.google.co.jp_group_android-developers_browse_thread_thread_e2f432707b735ff0
"trigger someeventtobringupnetworkinterface"
That would allow to use a custom setting for host and domain names that can be changed by SW, and adding that as another option into ROM Settings app or external app.
But the guy in question didn't succeed. What did he miss? Would it be better to do something like "on fakesystemproperty=something" and instead of manual trigger, doing "setprop fakesystemproperty something"?
I can probably test it and find out myself, but it would take loads of time compared to one of the kernel devs, and I don't even have the environment set up for modifying boot images. I was kinda hoping that one of the kernel devs would test it. I can write and post the modifications to init.rc and the custom script, they're very simple.
So, who can help me with answering the questions in the thread, and/or testing the modification?
Thanks! It's back.
Oh well, I'll keep preparing Ubuntu VM anyway
OK, first test fired - updated /init.rc in my own boot.img, checked the values. It's working, hostname is indeed modified.
Now I'll try to rewrite /init.rc in such way as to load the hostname setting from elsewhere, while not screwing the security. Will post results soon.
Setting it to the same value as the BT value would be ideal. I'm not sure how you could do that though, because the init scripts run before the frameworks load
Looking forward for a fix to this problem.
Update, but only partially on topic:
God, I hate SH scripting. Couldn't even google a normal tutorial that would explain where I went wrong. A script of 10 lines, and I can't make it work.
Let's see, I need something like this:
#!/system/bin/sh
echo "on service-exited-network_prepare" > /system/etc/net_init.rc
echo " ifup lo" >> /system/etc/net_init.rc
if [ -e "/system/etc/net_init.domain" ];
then
echo "hostname `cat /system/etc/net_init.host`" >> /system/etc/net_init.rc
else
echo "hostname localhost" >> /system/etc/net_init.rc
fi
if [ -e "/system/etc/net_init.domain" ];
then
echo "domainname `cat /system/etc/net_init.domain`" >> /system/etc/net_init.rc
else
echo "domainname localdomain" >> /system/etc/net_init.rc
fi
echo >> /system/etc/net_init.rc
Of course, this thing fails miserably with -
Syntax error: end of file unexpected (expecting "then")
What the hell am I doing wrong? Never used SH before, mostly tcsh and perl.
Thanks.
Oh well, I guess I got the problem.. Unix vs Windows file format. Sorry for bothering.
its always bothered me that you cant change the device name for wifi networks, and ive always looked for a way to change it.
kudos to you for the ambition and diligence to do it!
dont give up, if you can get it smoothed out enough im sure cyanogen will implement it in his next mod. ive always wished there was an option in wifi settings to change device name. itd be very useful for lan ip configuring and when your connected to a random hotspot lol
Ok, after fighting for a day, I still didn't manage to import another .RC file and run on service exit (I don't even see the trace of the process I'm trying to start - the first thing it does is attempting to write log, and there is no log, no matter where I put the start command), but at least for a "quick-and-dirty way" there's a very simple solution, given SD-EXT partition (I believe everyone creates it):
open terminal application, type the following command:
echo "echo YOURHOSTNAME > /proc/sys/kernel/hostname" > /sd-ext/userinit.sh
That would override the hostname of the system before boot completion.
After some reading, I believe there's nothing bad in setting the hostname twice - once default localhost in init.rc, and then overriding it using /proc/sys directory, Linux is designed to cope with that and hopefully so does Android.
So, as to pershoot's request, it's possible to write a small application to read Bluetooth device name value and write it as WiFi hostname, and include it in boot process right before 20userinit.
Now this is a task I'm not suitable for, I have no knowledge of frameworks whatsoever. Anybody up to the task?
Jack_R1 said:
After some reading, I believe there's nothing bad in setting the hostname twice - once default localhost in init.rc, and then overriding it using /proc/sys directory, Linux is designed to cope with that and hopefully so does Android.
So, as to pershoot's request, it's possible to write a small application to read Bluetooth device name value and write it as WiFi hostname, and include it in boot process right before 20userinit.
Now this is a task I'm not suitable for, I have no knowledge of frameworks whatsoever. Anybody up to the task?
Click to expand...
Click to collapse
I requested it and I'm not pershoot
Oops Sorry, my bad. Fever and lots of time in front of the computer don't do me good...
Kudos to you Jack_R1. Watching this.
Let me know if you need any help with shell scripting.
Gonna watch this and try it out later, the solution so far.
is this a stable fix?
is this confirmed to work?
Sorted out, updated with the most current info and several examples of custom ROMs.
Jack_R1 said:
Sorted out, updated with the most current info and several examples of custom ROMs.
Click to expand...
Click to collapse
I am running CM6 with a2sd and somehow the /sd-ext/userinit.rc is not executed. Even if I change permissions of the file to 777, it's not executed.
I also haven't found in init.d the script which executes userinit.rc, might be because I am running custom kernel? (wildmonks).
The only way for me to do it was to put the script in /etc/init.d/88userinit file and change it's permissions to 777
It's /scripts/userinit.sh, not userinit.rc
The execution of /sd-ext/userinit.rc used to be in /init.rc, in boot.img.
But the preferred way for most of the ROMs is to use /etc/init.d/ scripts anyway, since a lot of ROMs use them.
Changed the 1st post to reflect it.

Auto Keystore Unlocker

Hey Guys,
I know there is an app in the market already Keystore Unlocker, but it doesnt seem to work with the latest su binary. Does anyone know if there is a way to disable the password requirement for stored certificates. It would be a useful feature to bake into some roms or even a new app that works with latest su.
I decomplied the apk for Keystore Unlocker but it was no help. I emailed the developer and asked if he would either update the app and make it paid (99 cents wouldnt be too much) or release the source for us to use for future projects.
Let me know if you guys have any ideas.
Same issue on HTC Incredible, Stock + Root ROM 2.3.4. Really annoying, anyone know a fix? My initial thinking is it's at kernel layer, as Hot Reboot doesn't cause issue but a "full" reboot does. Anybody have a suggestion on fix or workaround?
+1
Would love to bypass the credential storage. It literally decimates the battery trying to log into a credentialed WiFi (try/fail/try/fail) if you don't happen to notice that you haven't done the credential yet.
+1
I have mailed to the app's author, perhaps he has a solution.
Does anybody knows what exactly the app does? Is there a way by command line to activate the credential storage? (so it could be done in autostart)?
There are two possibilities to unlock the keystore. Both need to be run under UID=1000!
1) You have an AOSP based ROM, like Cyanogen:
There is a tool called "keystore_cli", which provides basic access to the keystore by commandline.
Simply run
Code:
su -c 'keystore_cli u <password>' 1000
to unlock it.
Other options are can be found in keystore.c:
Code:
static struct action {
int8_t (*run)();
int8_t code;
int8_t state;
uint32_t perm;
int lengths[MAX_PARAM];
} actions[] = {
{test, 't', 0, TEST, {0}},
{get, 'g', NO_ERROR, GET, {KEY_SIZE}},
{insert, 'i', NO_ERROR, INSERT, {KEY_SIZE, VALUE_SIZE}},
{delete, 'd', 0, DELETE, {KEY_SIZE}},
{exist, 'e', 0, EXIST, {KEY_SIZE}},
{saw, 's', 0, SAW, {KEY_SIZE}},
{reset, 'r', 0, RESET, {0}},
{password, 'p', 0, PASSWORD, {PASSWORD_SIZE, PASSWORD_SIZE}},
{lock, 'l', NO_ERROR, LOCK, {0}},
{unlock, 'u', LOCKED, UNLOCK, {PASSWORD_SIZE}},
{NULL, 0 , 0, 0, {0}},
};
I guess you can figure them out, if you want to.
2) You don't have the keystore_cli tool:
a) You might be able to use a keystore_cli binary from another rom
b) Use unix domain sockets to communicate with the keystore.
The socket is under /dev/socket/keystore.
To access this, you'd have to write a small c programm and use the socket(), write() syscalls.
Luckily. this is exactly what that "keystore unlocker" from the market does.
It comes with a small native executable located at
Code:
/data/data/ru.chunky.AutoKeystore/lib/libkeystorecmd-executable.so
which reads input to send to the socket from stdin.
The format is:
Code:
<code><length1><message1>...
Where <code> would be 'u' to unlock
<length> would be the length of the password as 16bit unsigned int
<message> would be the string representation of the password
In this example the password is "password", which is 8 characters long.
So the length would have to be \0000\0008 and the message to send to the socket
Code:
u\0000\0008password
Running
Code:
su -c "echo -e 'u\0000\0008password' | /data/data/ru.chunky.AutoKeystore/lib/libkeystorecmd-executable.so" 1000
should show a result of
Code:
1
in the commandline, if successful and the keystore should be unlocked.
it sounds brilliant!
Do you have any idea what is the problem with the app and actual su versions?
Awesome find man, shame is ICS fixed this bug. It just requires a pattern lock or pin lock. I wish we could find a workaround for this....
Sent from my HTC Rezound
stm999999999 said:
it sounds brilliant!
Do you have any idea what is the problem with the app and actual su versions?
Click to expand...
Click to collapse
Nope, no idea.
I worked around it like this (cyanogenmod):
In /data/local/userinit.sh I put
Code:
#!/system/bin/sh
nohup /data/local/keystoreunlock_delayed.sh > /dev/null 2> /dev/null &
and the file /data/local/keystoreunlock_delayed.sh contains:
Code:
#!/system/bin/sh
sleep 60
su -c 'keystore_cli u <password>' 1000
The 60 second delay makes sure the phone has already initialized the keystore.
It's a bit of a diry way to do it, but this way it works without any android app.
To test this on my device, I made a file /data/keystoreunlock_delayed.sh
#!/system/bin/sh
su -c 'keystore_cli u <password>' 1000
and execute it within root explorer. But nothing happens!?
I tried su -c 'keystore_cli u <password>' 1000 in terminal Emulator, I got permission denied. I have to do a "su" before, without any parameters, then superuser asks for permission, and then the long command worked.
stm999999999 said:
To test this on my device, I made a file /data/keystoreunlock_delayed.sh
#!/system/bin/sh
su -c 'keystore_cli u <password>' 1000
and execute it within root explorer. But nothing happens!?
Click to expand...
Click to collapse
I forgot the permission 0755. It was 0555.
Can I download keystore_cli somewhere so I can use this script?
I have /system/bin/keystore but not keystore_cli on the rooted 2.3.4 OTA. Using HTC Incredible and would like to use this workaround script.
EDIT: I now realize this is in the Rezound forum. I found this thread by Google search but couldn't find much else on keystore_cli other than zip extract logs.
hm, I do not use a Rezound, too. I have a Desire.
Are you sure, this file is not an integral part of android?
I found one version on dropbox: https://www2.dropbox.com/s/cuu6hm8dvi3jxh5/BI/system/bin/keystore_cli
but I cannot say anything about this file. If it is genuine and ok.
What about asking in an Incredible subforum?
AutoKeystore fixed
I've just resolved "newer su" issue with ru.chunky.AutoKeystore and added password-less VPN Wizard there.

Paranoid Networking?

I have been having issues with the Paranoid Networking feature added to the Linux Kernel preventing some of my programs from creating sockets.
Appearently the process must be of a certain group id, either one of the AID_INET or AID_BT groups in the 3000's range I believe. I was cgreping through the source code and it seems a few calls to "in_egroup_p(gid_t)" are made to test if the process's group is 'correct' when ANDROID_PARANOID_NETWORKING is defined. If I understood the "in_egroup_p()" function, it should return 1 (retval) if there is a match. so what I did was this in the c file for inet in the kernel. I hope the kernel gets compiled, I just did a "make clean" and "brunch d2spr" it is cm-10.1
Code:
#ifdef ANDROID_PARANOID_NETWORKING // this was there
if ( in_egroup_p(0) == 1) {
return 1;
} // I added this
return in_egroup_p(AID_INET) || capable(I_FORGOT_HERE); //this was there
And I am hoping that when I execute the program as root, it will have permission to create a socket. Also note, that the programs I am having problems for are glibc based that I copied and mounted from a .img file. Programs such as postresql, gdm3, and others. It is a debian distro that I mount with an init service when a property is set to 1.
If this does not work, I will need to run without the Paranoid Networking patch to the kernel. What config file do I need to edit so that ANDROID_PARANOID_NETWORKING does not get defined or built into the kernel?
edit: I feel like this, " IM ROOT B****, STAY OUTTA MY WAY! " And then that scene from Jurrasic Park comes to mind
http://www.youtube.com/watch?v=RfiQYRn7fBg
Still no go
Code:
[email protected]:/etc/init.d# ./postgresql start
[....] Starting PostgreSQL 9.1 database server: main[....] The PostgreSQL server failed to start. Please check the log output: 2014-01-06 16:48:59 UTC LOG: could not create IPv6 socket: Permission denied 2014-01-06 16:48:59 UTC LOG: could not create IPv4 socket: Permission denied 2014-01-06 16:48:59[FAILWARNING: could not create listen socket for "localhost" 2014-01-06 16:48:59 UTC FATAL: could not create any TCP/IP sockets ... failed!
failed!
*BEEP* *BEEP* *BEEEEEEEEEEP*
Hmmm... Maybe the kernel didn't compile? I dunno . ...
Where is the config file for the kernel that comes with CM-10.1 so I can turn off this paranoid networking?
My philosophy is that they shouldn't be there to start a socket in the first place, but if I want to, I should be able to. This is where I need something akin to sudo, but as root this is pissing me off, let me create a socket por favor!
I tried a lot of things but this just isn't working right. Some one please, help.
I've about had it up to my neck with Android. ****ing bull ****, I didn't know I was buying a bad ass phone with Chains and Iron Bars for an OS. FREEEEEEEDOOOOOOMMMMMNNNNNNNNN
After breaking my build, I deleted my kernel directory tree and re-sync'ed. I then did "source build/envsetup.sh" and "breakfast d2spr" and then I when to "kernel/samsung/d2/" and did "make menuconfig" then I unselected in networking options "Only specific groups can create sockets" or some such option. and then "brunch d2spr". We shall see if that works.
Update:
Did not work. Said unfinished jobs yada yada
So what I am trying now.
I cleaned everything, bummer!
I copied my kernel dir to another location
I pulled my kernel config with adb
I used that with 'make menuconfig' and edited out the 'only allow certain groups' bit
I saved that
copied it to my source in kernel/samsung/d2/
I edited AndroidKernel.mk to use that config file instead ( the assignment occurs at the top of the file)
croot
brunch d2spr
waiting till tomorrow more than likely....
Update: ( 3 hours later )
Its taking long enough
seems to be working
maybe I can make a config in my source tree and then make mroper and clean, aswell as in the KERNEL_OBJ dir in out/*, then brunch. to avoid needing two kernel source trees and some confusion in case I modify any of the source and not just the config.
AndroidKernel.mk specifies which config file to use instead of the other pre-configured files, just start by pulling a config off your phone with the same rom and device your building for.
Code:
adb pull /proc/config.gz
That will pull the conpressed file off your phone to the current working directory, then gunzip it. Then launch
Code:
make menuconfig
from your kernels root dir, for me that is "/home/$USER/android/system/kernel/samsung/d2/"
And then once the menu is up, use the arrows to scroll down to the bottom and use enter or return to select the option to use a different configuration file, it should change menus to one with ".config" erase that and change it to point to your config file, I just copied mine to the same directory mentioned above with the name "config" the same without the "." (dot/period) in front.
After that, from the same dir ( as well as in the KERNEL_OBJ/ dir somewhere within the out/ dir)
Code:
make mrproper && make clean
to clean the previous kernel make.
After all of that, you can 'croot' and 'brunch $YOUR_MODEL', but not before making sure you change which config file to use in your kernel's root dir in it's AndroidKernel.mk file. Its at the top, I used an absolute path for my installation, just in case.

[Q][SOLVED]Writing into ramdisk from init.rc

EDIT: The solution is in post #6.
Hi,
I'm trying to make a kernel modification which would create a file on boot before any partition is mounted. I wrote a simple shell script which tries to create a file in the root directory. The problem is I can't write any file to the / directory from a program or a script called by exec from init.rc. If I run dmesg, I can't find any indication of a problem there. I tried to modify the script to write to the /data directory on post-fs, and that worked, but that is not what I want.
I can't find out where the problem is. Do you have any ideas? Thanks.
simplified init.rc snippet:
Code:
on fs
# some work
exec /sbin/busybox sh /test.sh
# some other work
mount_all /fstab.grouper
# and another work
/test.sh
Code:
#!/sbin/busybox sh
echo "test" > /test
/ mounts as ro pretty early...
try to remount it rw before making files, or change the part of init.rc that mounts it ro.
frantisek.nesveda said:
Hi,
I'm trying to make a kernel modification which would create a file on boot before any partition is mounted. I wrote a simple shell script which tries to create a file in the root directory. The problem is I can't write any file to the / directory from a program or a script called by exec from init.rc. If I run dmesg, I can't find any indication of a problem there. I tried to modify the script to write to the /data directory on post-fs, and that worked, but that is not what I want.
I can't find out where the problem is. Do you have any ideas? Thanks.
simplified init.rc snippet:
Code:
on fs
# some work
exec /sbin/busybox sh /test.sh
# some other work
mount_all /fstab.grouper
# and another work
/test.sh
Code:
#!/sbin/busybox sh
echo "test" > /test
Click to expand...
Click to collapse
I am having the same problem, my script is not called. Did you find the solution?
Khaon said:
I am having the same problem, my script is not called. Did you find the solution?
Click to expand...
Click to collapse
Not yet. But recently I got back to the project where I would use it, so maybe I can take a look again and see if I am any wiser now. I'll try to solve it this evening or tomorrow, I'll be reinstalling my tablet so I'll have a good oportunity. I'll post the results here.
frantisek.nesveda said:
Not yet. But recently I got back to the project where I would use it, so maybe I can take a look again and see if I am any wiser now. I'll try to solve it this evening or tomorrow, I'll be reinstalling my tablet so I'll have a good oportunity. I'll post the results here.
Click to expand...
Click to collapse
That would be great, the only thing I could see is upon booting its permissions are read-only. And chmod 0777 doesn't change its permissions(rootfs is rw)
Khaon said:
That would be great, the only thing I could see is upon booting its permissions are read-only. And chmod 0777 doesn't change its permissions(rootfs is rw)
Click to expand...
Click to collapse
OK, I found the cause of the problem and the solution.
The implementation of the exec command in Android init scripts is missing from the init binary by default - the source looks like this:
Code:
int do_exec(int nargs, char **args)
{
return -1;
}
So there are two options - either write the do_exec function yourself, or use a trick to execute your programs.
Writing it yourself would be probably cleaner, but it would mean compiling the init binary again and not everyone wants to do that, so I'll be using the trick.
The trick is to register your program as a service and then invoke it via the start command.
Example init.rc:
Code:
# service invocation - where you need it
# warning - this will not wait for the finish of the program
start my_awesome_program
.
.
.
# service declaration - along with other declarations at the end of the file
service my_awesome_program /sbin/my_awesome_program
disabled
oneshot
If you want to implement the do_exec function and use the exec command, you can use for example CyanogenMod's implementation.
There may be a third option, but I haven't tested that - you can copy the init binary from a kernel which has the exec command working - I suppose all CM kernels should, but I haven't tried.
It's funny how when you already know the solution, you can find so much info, but when you don't, nothing comes up since you are searching wrong.
frantisek.nesveda said:
OK, I found the cause of the problem and the solution.
The implementation of the exec command in Android init scripts is missing from the init binary by default - the source looks like this:
Code:
int do_exec(int nargs, char **args)
{
return -1;
}
So there are two options - either write the do_exec function yourself, or use a trick to execute your programs.
Writing it yourself would be probably cleaner, but it would mean compiling the init binary again and not everyone wants to do that, so I'll be using the trick.
The trick is to register your program as a service and then invoke it via the start command.
Example init.rc:
Code:
# service invocation - where you need it
start my_awesome_program
.
.
.
# service declaration - along with other declarations at the end of the file
service my_awesome_program /sbin/my_awesome_program
disabled
oneshot
If you want to implement the do_exec function and use the exec command, you can use for example CyanogenMod's implementation.
There may be a third option, but I haven't tested that - you can copy the init binary from a kernel which has the exec command working - I suppose all CM kernels should, but I haven't tried.
It's funny how when you already know the solution, you can find so much info, but when you don't, nothing comes up since you are searching wrong.
Click to expand...
Click to collapse
Oh my, many thanks! So stupid exec always return ;D, wouldn't have thought one sec on checking the implementation of those functions.
Khaon said:
Oh my, many thanks! So stupid exec always return ;D, wouldn't have thought one sec on checking the implementation of those functions.
Click to expand...
Click to collapse
A small warning - starting the program as a service will not wait for the program finish, so its results will not be available immediately after the start call. I learnt this the hard way after a few hours of debugging just now.
I added this info to my previous post too.
frantisek.nesveda said:
A small warning - starting the program as a service will not wait for the program finish, so its results will not be available immediately after the start call. I learnt this the hard way after a few hours of debugging just now.
I added this info to my previous post too.
Click to expand...
Click to collapse
I always use
Code:
class core
user root
in addition to oneshot.
Haven't you com accross SElinux restrictions using busybox? Because I do I need to set permissions.
I have this issue

Android 6.0 Kernel root requirements.

Have a feeling I will figure this out before answered and probably some snide smartest person in the room syndrome remarks but could help save me and some others time so going to bite the bullet and ask anyway. With Android 6.0 what makes some Kernels compatible for root and others not. Have read some tidbits in otherwise unreliable sources it has to do with Selinux being set for permissive mode. If true is this in the Kernel or can it be set in the Ramdisk? Link to a commit would be extremely helpful.
Otherwise have 3 builds going now. If correct pretty sure one of the 3 will work but confirmation makes me feel better.
chairshot215 said:
Have a feeling I will figure this out before answered and probably some snide smartest person in the room syndrome remarks but could help save me and some others time so going to bite the bullet and ask anyway. With Android 6.0 what makes some Kernels compatible for root and others not. Have read some tidbits in otherwise unreliable sources it has to do with Selinux being set for permissive mode. If true is this in the Kernel or can it be set in the Ramdisk? Link to a commit would be extremely helpful.
Otherwise have 3 builds going now. If correct pretty sure one of the 3 will work but confirmation makes me feel better.
Click to expand...
Click to collapse
https://github.com/Elite-Kernels/elite_shamu/commit/c91d04bb34b327d66212090a0de36aa29bd6840b
Done in kernel
Sent from my Nexus 6 using Tapatalk
buckmarble said:
https://github.com/Elite-Kernels/elite_shamu/commit/c91d04bb34b327d66212090a0de36aa29bd6840b
Done in kernel
Sent from my Nexus 6 using Tapatalk
Click to expand...
Click to collapse
Thanks had worked out in one of the three I was testing using SuperSu 5.1. Why I am trying to school myself on new changes it seems I am now encrypted by default using the same files (fstab.shamu) that I used in 5.1.1. Are you aware of any changes now required for 6.0? admittedly am using the same Anykernel set up as I had with Lollipop and am new to using the Anykernel method for flashing kernels as in the past would just compile the boot.img. Honestly had been used to releasing my own Roms and not just Kernels so some of these things are new.
Sorry I am not ashamed to admit when something simple is throwing me for a loop and ask even if makes me look like a dumb ars.
chairshot215 said:
Thanks had worked out in one of the three I was testing using SuperSu 5.1. Why I am trying to school myself on new changes it seems I am now encrypted by default using the same files (fstab.shamu) that I used in 5.1.1. Are you aware of any changes now required for 6.0? admittedly am using the same Anykernel set up as I had with Lollipop and am new to using the Anykernel method for flashing kernels as in the past would just compile the boot.img. Honestly had been used to releasing my own Roms and not just Kernels so some of these things are new.
Sorry I am not ashamed to admit when something simple is throwing me for a loop and ask even if makes me look like a dumb ars.
Click to expand...
Click to collapse
to remove force encryption you need to change "forceencrypt" to "encryptable" in the fstab for userdata. This will not automagically decrypt you, so if you flashed factory images, you will be encrypted again. You will need to format data in TWRP to decrypt again.
I just pushed my anykernel to Github so could post but is pretty much what I had done. what I had done was working after either format data or performing a factory reset with 5.1.1. Starting to think maybe my factory image flash had gone wrong. Could just be a change I am not aware of but did not see the optimizing apps screen after wiping. What I had essentially done is after flashing factory image rebooted bootloader and before booting the first time flashed TWRP installed my Kernel, flashed SuperSu 5.1 and then did a full cache and data wipe.
Admittedly with anykernel I had started by downloading another Kernel, forget which one and then removed or adding what I believed should for my Kernel. So far besides the little encryption issue seems to be working out OK. Trying to keep the Kernel as effective as possible with the fewest possible trade off’s. Not much original work in the sense a lot has already been done but have done lots of testing for efficiency.
Anykernel
https://github.com/Starship-Android/anykernel
chairshot215 said:
Have a feeling I will figure this out before answered and probably some snide smartest person in the room syndrome remarks but could help save me and some others time so going to bite the bullet and ask anyway. With Android 6.0 what makes some Kernels compatible for root and others not. Have read some tidbits in otherwise unreliable sources it has to do with Selinux being set for permissive mode. If true is this in the Kernel or can it be set in the Ramdisk? Link to a commit would be extremely helpful.
Otherwise have 3 builds going now. If correct pretty sure one of the 3 will work but confirmation makes me feel better.
Click to expand...
Click to collapse
buckmarble said:
https://github.com/Elite-Kernels/elite_shamu/commit/c91d04bb34b327d66212090a0de36aa29bd6840b
Done in kernel
Click to expand...
Click to collapse
That is actually a *really bad hack*, since it disables selinux rather than manipulating the policy in an appropriate manner to make root usage possible.
The correct changes are actually *outside* of the kernel itself, in the sepolicy file in the ramdisk.
That sepolicy file is generated based primarily on what is in these repositories;
https://android.googlesource.com/platform/external/sepolicy/
https://android.googlesource.com/device/moto/shamu/+/master/sepolicy/
You see, there are some interesting commits, like this; https://android.googlesource.com/pl...243e5cf4f8898b7acedc24efd58fdcd163e3048^!/#F0
What that one does, is it tells selinux to never allow the sepolicy to be reloaded from the system_server context.
Or this one here, which does the same for the init context;
https://android.googlesource.com/pl...cy/+/6d0e9c8f4ee4f326b2c2851fa2851193fec33a4e
But note: partially reverted here;
https://android.googlesource.com/pl...abd409af0e7d7fb908e5f04fa1ed946e2996dce^!/#F0
That partial reversion actually provides a very useful HINT about it;
# Note: this requires the following allow rule
# allow init kernel:security load_policy;
# which can be configured on a device-by-device basis if needed.
In other words, add that line to this file;
https://android.googlesource.com/device/moto/shamu/+/master/sepolicy/init.te
Then *init* will re-gain the ability to change and reload selinux policies.
HOWEVER, instead of doing that, you might consider going a little further, by enabling THIS in a sortof-user-build;
https://android.googlesource.com/platform/external/sepolicy/+/master/su.te
... and adding domain_auto_trans from untrusted_app to su, and various other adjustments/tweaks.
I think that there is a neverallow rule in there somewhere that will complain if you make that change, so you'll have to kill the neverallow rule... yep, app domain:
https://android.googlesource.com/platform/external/sepolicy/+/master/app.te#286
**note: a neverallow rule is NOT a runtime enforcement directive. selinux defaults to block until a positive allow rule is created. The neverallow rules are used to annoy you when you try to build an sepolicy from source that violates something.
What *I* would do first, is fix that neverallow rule in app, add the auto-transition to su, and run a make bootimg for *USERDEBUG*. You probably should also edit the fstab a bit while you are at it to kill the "verify" parameter from /system, and swap the "forceencrypt" to "encryptable" for /data.
ALL of the changes (besides removing the neverallow rule) can be made in the shamu device tree.
This should produce a boot.img that relaxes selinux a bit to allow su. And from there, the su binary can be root.root/6755, WITH the file context set to su_exec, and you should have root back.... note: su daemon should *NOT* be required with these changes. In fact, you could even proof of concept using "cp /system/bin/sh /system/bin/su; chown root.root /system/bin/su; chmod 6755 /system/bin/su; chcon su_exec /system/bin/su" <-- you will have to look more at the chcon first parameter though, I haven't actually had to use it though, so I'm not entirely sure of what it expects as input. Note the boldness of "proof of concept"... it would be very... unsafe... to actually keep it like that on any device that you actually need to trust.
phhusson's new fork of superuser *should* be able to handle the job, with only minor adjustments to su.c's su_main() function where it is deciding to run connect_daemon() or su_main_nodaemon(). It would need to run su_main_nodaemon() with these changes.
So I've actually been working on this myself, since it is impossible to trust chainfire or his new employer (who is systematically buying up ALL of the root provisioning software for Android), and I have come up with this as an interim step;
Code:
diff --git a/app.te b/app.te
index 40de074..98bb663 100644
--- a/app.te
+++ b/app.te
@@ -283,7 +283,7 @@ neverallow appdomain { domain -appdomain }:process
# Transition to a non-app domain.
# Exception for the shell domain and the su domain, can transition to runas,
# etc.
-neverallow { appdomain -shell userdebug_or_eng(`-su') } { domain -appdomain }:process
+neverallow { appdomain -untrusted_app -shell userdebug_or_eng(`-su') } { domain -appdomain }:process
{ transition dyntransition };
# Write to rootfs.
diff --git a/domain.te b/domain.te
index 0f6c6da..b1d7c41 100644
--- a/domain.te
+++ b/domain.te
@@ -396,7 +396,7 @@ neverallow domain { file_type fs_type dev_type }:{ lnk_file fifo_file sock_file
# Nobody should be able to execute su on user builds.
# On userdebug/eng builds, only dumpstate, shell, and
# su itself execute su.
-neverallow { domain userdebug_or_eng(`-dumpstate -shell -su') } su_exec:file no_x_file_perms;
+neverallow { domain -init -untrusted_app userdebug_or_eng(`-dumpstate -shell -su') } su_exec:file no_x_file_perms;
# Do not allow the introduction of new execmod rules. Text relocations
# and modification of executable pages are unsafe.
diff --git a/init.te b/init.te
index 41eafe2..e7dd87a 100644
--- a/init.te
+++ b/init.te
@@ -123,7 +123,7 @@ allow init security_file:dir { create setattr };
# Reload policy upon setprop selinux.reload_policy 1.
# Note: this requires the following allow rule
-# allow init kernel:security load_policy;
+allow init kernel:security load_policy;
# which can be configured on a device-by-device basis if needed.
r_dir_file(init, security_file)
@@ -283,4 +283,5 @@ neverallow init shell_data_file:lnk_file read;
neverallow init app_data_file:lnk_file read;
# init should never execute a program without changing to another domain.
-neverallow init { file_type fs_type }:file execute_no_trans;
+allow init { file_type fs_type }:file execute_no_trans;
+allow init kernel:security read_policy;
diff --git a/keystore.te b/keystore.te
index 83a0e85..d742d30 100644
--- a/keystore.te
+++ b/keystore.te
@@ -24,7 +24,7 @@ selinux_check_access(keystore)
###
neverallow { domain -keystore } keystore_data_file:dir ~{ open create read getattr setattr search relabelto ioctl };
-neverallow { domain -keystore } keystore_data_file:notdevfile_class_set ~{ relabelto getattr };
+neverallow { domain -keystore -init } keystore_data_file:notdevfile_class_set ~{ relabelto getattr };
neverallow { domain -keystore -init } keystore_data_file:dir *;
neverallow { domain -keystore -init } keystore_data_file:notdevfile_class_set *;
diff --git a/su.te b/su.te
index d4a488b..1d1f6da 100644
--- a/su.te
+++ b/su.te
@@ -7,6 +7,7 @@ userdebug_or_eng(`
# wrapped to ensure that it does not exist at all on -user builds.
type su, domain, mlstrustedsubject;
domain_auto_trans(shell, su_exec, su)
+ domain_auto_trans(untrusted_app, su_exec, su)
# Allow dumpstate to call su on userdebug / eng builds to collect
# additional information.
diff --git a/vold.te b/vold.te
index b22436f..fa1a879 100644
--- a/vold.te
+++ b/vold.te
@@ -164,7 +164,7 @@ allow vold self:capability sys_chroot;
allow vold storage_file:dir mounton;
neverallow { domain -vold } vold_data_file:dir ~{ open create read getattr setattr search relabelto ioctl };
-neverallow { domain -vold } vold_data_file:notdevfile_class_set ~{ relabelto getattr };
+neverallow { domain -vold -init } vold_data_file:notdevfile_class_set ~{ relabelto getattr };
neverallow { domain -vold -init } vold_data_file:dir *;
neverallow { domain -vold -init } vold_data_file:notdevfile_class_set *;
neverallow { domain -vold -init } restorecon_prop:property_service set;
Some of those are what reverse engineering I've managed to accomplish on the policy changes required for supersu, and some of them are working towards a better root control infrastructure.
In any case, if you patch platform/external/sepolicy with that, then run a "make bootimage", it *WILL* actually work with supersu.
** note: make sure that you repo init against the android-6.0.0_r1 release branch if you want it to actually be compatible with factory builds. Master has a LOT of MAJOR changes since then and it does not work.
Also note: don't forget to patch platform/device/moto/shamu/fstab.shamu to kill the verify and optionally forceencrypt parameters.
I'm just going to leave these two links right here....
https://github.com/lbdroid/AOSP-SU-PATCH
https://github.com/phhusson/Superuser
That will yield an ENFORCING, and NON-RELOADABLE selinux policy, allowing root, and all bundled into the boot.img in order to maintain the integrity (dm-verity) of the system image!
Take THAT Coding Code Mobile Technology LLC!!!!!
And for people who want to know the true history of things (rather than worshiping people who distribute binaries....), please read this; http://www.koushikdutta.com/2008/11/fixing-su-security-hole-on-modified.html and then look at the github label (that says "forked from") on the Superuser repository I linked above.
doitright said:
I'm just going to leave these two links right here....
https://github.com/lbdroid/AOSP-SU-PATCH
https://github.com/phhusson/Superuser
That will yield an ENFORCING, and NON-RELOADABLE selinux policy, allowing root, and all bundled into the boot.img in order to maintain the integrity (dm-verity) of the system image!
Take THAT Coding Code Mobile Technology LLC!!!!!
And for people who want to know the true history of things (rather than worshiping people who distribute binaries....), please read this; http://www.koushikdutta.com/2008/11/fixing-su-security-hole-on-modified.html and then look at the github label (that says "forked from") on the Superuser repository I linked above.
Click to expand...
Click to collapse
Thanks I have been bed ridden for a bit but will look over all these things. In short my last build I first flashed chainfires boot.img and rooted before flashing my Kernel. Was able to do this without putting my Kernel into permissive mode. Had also unpacked the chainfire boot.img and used a few things in my boot image and used Meld and made a few other edits based on chainfires boot.img. Still having an issue with encryption being forced that just has me baffled. Was otherwise a temporary quick fix for not having to put the Kernel into permissive mode.
Definitely appreciate all the feedback and am learning allot so thanks for that everyone.
Otherwise the Encryption is driving me mentally insane. Like straitjacket throwing myself around a small room with rubber walls and a door with a slot that keeps opening with a tray of drugs and food sliding in insane. It has become so frustrating.
this is the fstab I am using and see know issue. Have also tried Despair, Vortex and the fed_patcher patch not to mention Chainfires Kernel for Root and no matter how many times I wipe data or factory reset it is always encrypted. If it was not knowing the encryption is done via software would swear something is wrong with the phone. Have also changed up TWRP 3 times as noticed I no loner see updating apps but that is also the same in that encription is still forced
https://github.com/Chairshot215/anykernel/blob/master/ramdisk/fstab.shamu
The problem you are running into, is that recovery doesn't actually *format* the userdata partition, which means that a factory reset from recovery won't *remove* the encryption. The reason it doesn't format is to prevent the deletion of /data/media directory, which gets mapped to /sdcard.
What you need to do, is reboot to bootloader, and run "fastboot format userdata".
If you aren't permissive, then the big thing you must have taken from chainfire's boot.img, is the sepolicy file. He only actually changed two files; sepolicy and fstab.shamu.
The thing to be aware of, though, is that his supersu, despite running selinux enforcing, is actually putting a lot of domains into permissive. When you go through your kernel audit log, you should pay attention to the end of the audit log where it says "permissive=1" or "permissive=0". You will find a lot of "permissive=1". Using *my* sepolicy, which is NOT compatible with his supersu, you will find that ALL domains remain enforcing, yet we aren't increasing the authority of any domain besides the "su" domain, AND, there will actually be far fewer denials against root/su. On top of that, I actually block the su domain from messing with kernel security. In other words, we do NOT allow the su domain to change selinux to permissive, OR to reload the policy. Both of those ARE permitted in chainfire supersu, which is incredibly dangerous, given how root is typically used on Android.
To put that into perspective, the ability to change the enforcement status or reload the policy, makes it possible for a malicious application to modify the boot.img to disable dmverity on the system partition, and compromise the system partition. My approach makes it possible to maintain the integrity of the boot partition and therefore maintain dmverity on the system partition, while providing root access. This makes unauthorized changes to the system partition immediately obvious and ineffective, since dmverity will refuse to read changed data, instead returning an i/o error.
The verity keys are actually stored on the boot.img, which means that it is still possible to make *intentional* changes to the system partition (through regenerating the key), and prevent unauthorized changes.
I've been considering adding a new domain to the effect of "su_sensitive" that will enforce strong password input for every authorization request in order to grant kernel security permission, but it remains to be seen if this would even be helpful to anyone.
How do you even edit a kernel? If you could explain, please do so.

Categories

Resources