This has always been doable on the N900, but as far as I know no one's ever really bothered doing it. I knew for years it was possible in principle, knew for about a year how to do it, but didn't have the occasion to.

Well, I just "upgraded" back to the N900 from the N9 (you served me well N9, I still love you, but you're no N900), and this time around I decided "what the heck, I could use these 9+ free hours to be productive, OR I could script up this thing that no one really needs but is sorta fun and allows me to 'bootstrap' up to root access on a stock N900 without any external help or tools. Oooo and even better, then I could spend another 12+ hours writing up a thorough tutorial about how I did it, because people might enjoy reading it and/or learn something from it." (Of course taking this much time to write something was also helpful to me already, it caused me to spend a lot more time contemplating/reconsidering/reviewing/rechecking what I did/decided.)

Normally, when we want to get root access on our N900s right after a fresh flash, we have a couple of options: install rootsh/sudser/sshd etc, any package that directly or indirectly opens a way for us to get a root shell on our N900s, or go the 'official' way and turn on R&D mode, which lets us through the Nokia-included /usr/sbin/gainroot command. But sometimes you might not have access to either for whatever reason, and maybe, just maybe, if/when that time comes you'll remember enough details from this post that you'll be able to redo it from memory. Or more likely, you'll just find this post informative/interesting for other reasons.

For starters, let's explain the broad-strokes reasoning:

We know that the stock N900 will have the following things:
1. busybox (has a decent, if smallish, set of standard UNIX-y tools built in)
2. XTerm (allows you access to #1)
3. hildon-application-manager (The "App Manager" app, hereby referred to as "HAM". HAM will install any valid .deb file we give it that also matches HAM's own special criteria. When it does so, it will do the install process with root privileges, including any of the .deb's {pre/post}{rm/inst} scripts - this is why all those aforementioned packages in the repos are able do set us up with root access one way or another.)

So, in principle, all we need is:
1. To write a script which, when run as root, will change the system in a way that enables us to become root. (There are many different ways to do this, but once we know how we can trivially do this with a plain-text editor)
2. To wrap that script up in .deb file which will contain the script as its 'preinst' or 'postinst' script. (This is the hard part, because we have to know the layout of a .deb package - we can't rely on automated tools.)

Then we just tell HAM to install that .deb file, either by navigating to it using built in File Manager, or by running the dbus command to invoke HAM's install-this-deb-file behavior through that.

For those who are interested: See next posts for much more detail:
My preferred 'get access to root' configuration, and reasoning
.deb format basics and how I did all the deb metadata files
.ar format basics and how to assemble+install the .deb
Example implementation

P.S. I hope it's obvious, but if you feel this is over your head, by all means, feel free to ask questions, but please don't go trying this on your devices if you don't already feel comfortable using the shell/xterm on your N900(s). For example, if look at the command at the end of the assemble+install section, and don't realize that "$DEB" is a variable for the .deb file (which you must either define in the shell with a previous command, or replace with the actual filepath in the command itself), then you probably want to take some more time to understand what the shell commands mean before proceeding. Similarly, if you screw up editing the /etc/sudoers file, (or any files in /etc/sudoers.d/), then you can lock yourself out of root access.

[edit1]
After some fiddling, I feel that this is a slightly better script:
The difference is that we are patching just the 'master' 01sudoers and then running Nokia's update-sudoers kludge-script (kludging around the fact that the builtin sudo doesn't source /etc/sudoers.d properly). The earlier script left the new sudoers lines outside the comment blocks update-sudoers orients by, so the next time update-sudoers runs (e.g. trying to install CSSU), it gets confused and leaves the new lines at the bottom when regenerating /etc/sudoers (which then messes things up because bottom lines override prior ones). An alternative is to use '2' instead of '1' as the line at which to insert the new sudoers lines, which would mean ugly code repetitiveness if we wanted to patch both files ourselves.
[/edit1]

This is the script I used in my .deb to set up root access:
So there are a lot of different ways the exact give-self-root-access could be done. I think this way is one of the better ones, but there can be good reasons for doing it somewhat differently.

Here's what the above script does:

I modified the sudoers configuration (this is what determines what commands sudo allows which users to run, as who, etc), to do the following things:
1. The main "user" user can run /any/ command as /any/ user, BUT has to enter their password to do so.
2. The root user can run any command as any user, without having to enter its password (Note: this doesn't compromise any security. The root user can already do everything and anything it wants. Common legitimate usecases of running sudo when already root: running scripts/programs written for general use which invoke sudo, or to run commands as any other user.)
3. Because changes 1 and 2 are both more flexible and more secure than the 'sudo gainroot' approach, I delete the now-redundant line allowing the main "user" user to run gainroot without any authentication. If you don't intend on installing rootsh and you are not in R&D mode it should be safe to skip this step, but several packages actually pull rootsh as a dependency, so yeah.

(More in-depth reasoning on this below.)

I apply this change to both the 'actually used' /etc/sudoers file, and the 'master' /etc/sudoers.d/01sudo file.

The former causes the changes to take effect immediately, and the latter will keep the changes from getting clobbered the next time 'update-sudoers' is ran. In a normal sudo setup, this would be unnecessary. But in the stock N900, only /etc/sudoers is actually read, so instead it's dynamically regenerated with the script 'update-sudoers' by concatenating all of the existing files in /etc/sudoers.d/. This is aberant behavior and I hope we will do something about that in the near future (I have compiled a proper sudo on one of my N900s a few weeks back finally, and have started that migration personally, and I hope I or someone else will find the time to package that up for our repos as well).

Anyway, then the script deletes the password for the main "user" user and launches an osso-xterm with the passwd command, giving you the opportunity to enter in a new password.

On a stock N900, the user's passwd field has the value "!", which basically means the account is locked to any normal logins and the password is blank - the 'lock' part prevents you from being able to configure your password (the actual Linux user password, not the phone lock code or whatever) with the passwd command. Note: "passwd -u user" would also work here, but passwd -d seems to always wipe out the lock as well, so using the -d flag also allows this to work in the event that someone has ended up in a state where the "user" user's password is set, but they don't remember/know that this happened - maybe some other package set the "user" user's password and they forgot, or maybe you actually used this approach more than once on the same N900 - on repeat runs the password will already be set, but maybe you were trying to cancel/abort the run, and ended up accidentally setting your password to something you didn't pay attention to instead of just closing the XTerm window (I did this a few times myself when testing this, because I am so used to "Ctrl+C" or "Ctrl+D" being ways to abort out of command-line programs).

Note that there IS a theoretical time window when another process running as the "user" user (so, most of them on the N900) could, if it was malicious, set the password of the user, thereby locking the user out of being able to reset their password - it would have to happen right between the 'passwd -d user' and 'osso-xterm passwd' commands. If successful, that leads to immediate priviledge escalation opportunity vs a purely stock N900 (since you need the password to run root commands and the password-setting process has that password). HOWEVER, to be absolutely clear, this is another very-very-unlikely scenarios, and more importantly, if you were in that situation, again, a malicious process running as your user can just do the steps this entire guide is about, and get root access that way. In the unlikely event that you ever do actually DO this guide's steps, you'll probably be in a situation where you've got a freshly flashed N900, which is an immeasurably MORE safe situation than the way most of us use our N900s day-to-day.

sudoers configuration rationalle:

Now, I know that rootsh, the most commonly used package to get root, leaves sudoers alone, and instead replaces the existing /usr/sbin/gainroot script (which the stock sudoers configuration allows the user to run) with one that gives you a shell without first checking if you are in R&D mode. I think sudser does the same thing or something like it by default.

But after having started my Linux experience about five years ago on the N900, and having grown substantially in Linux usage since then, I've decided that I really don't like that way of doing things.

0. My way is more standard/proper/conventional: it's more in line with typical desktop sudoers setups, in as much as the limited/quirky sudo Nokia chose to build for our N900s is used. And I don't just mean that in a comformist way. I think the standard way in this instance is better for several reasons that follow:
1. I don't like 'gainroot' (well, I like how the name sounds, but besides that): It's a Nokia-created, not-standard-across-any-other-systems, command. I don't like 'devel-su' on the N9 and the Jolla phones for the same reasons. I am pretty sure that gainroot in its stock form is the byproduct of corporate goals/attitudes (product support, liability, etc: note how they are all expressly focused on enabling developers - the stock gainroot in particular just basically insults your desire to have root access if you're not in R&D mode). Modifying/replacing gainroot the way rootsh does seems to me like trying to reshape an initially misguided setup into a concordantly sub-optimal improvement.
2. The 'rootsh' way is the security-equivalent of just removing your front door off its hinges: Virtually all software on the N900 runs as the same user as the actual person using the phone, the "user" user. And the stock sudoers configuration just lets that same user invoke gainroot. And any and all commands can be ran through gainroot. No thanks.
3. 'sudo' by itself provides much more flexibility (proper full featured sudo even more so, but even without it, this statement stands). For example, if you want to run a command as the 'lighttpd' user for whatever reason, instead of as root, with my configuration, you can. And if you want to run just a command, instead of opening a shell for just one command, you just do 'sudo $COMMAND' don't have to do backwards syntax where you basically run one command to print out the command you want and pipe that output into 'sudo gainroot'.
4: Overall, my setup is much more flexible. (If we had had THIS setup from the beginning, we wouldn't have had as much pressure on packages to clutter our /etc/sudoers.d/ folder with so many entries. And if Nokia also gave us a proper sudo with askpass support, our sudoers folder could remain basically pristine - and GUI programs, just as CLI ones, could simply prompt the user for a password if they needed to elevate priviledges... You know, like the civilized operating system distributions do it.)

Also, the more standard upstream way is to add users to the 'sudo' group, and let the sudo group have the permissions I've given the "user" user directly. I tried this (and it works fine on my N900 with the fully-fledged sudo build), but with the Nokia-provided stock sudo, it seems to completely ignore the "PASSWD" clause in the sudoers file for users in the sudo group, and instead just happily lets you run all commands with sudo without prompting for a password.

Anyway, the way my example script does it is a slightly more user-friendly and slightly more conventional way of setting up sudoers than my personal setup is. I personally do some other tweaks on top of that to limit stuff even more - I set "Defaults rootpw" for instance, because I want to segregate ability to log into my device as "user" from the abiltiy to run arbitrary commands as sudo (and virtually every advantage of using the user's password instead of root's is largely inapplicable in a virtually-always single-user system like the N900).

Now that said, you can obviously set it up however you're happy with - you just need to know how to do it, and this is the method I thought was best, so it's the one I did myself and have first hand experience testing fairly thoroughly. From here, we go on to build the actual .deb file.

".deb" format basics:

Basically, a .deb file is an archive of the same format that the "ar" utility uses, containing the following things:
debian-binary: A text file which roughly speaking, says what version of the .deb file format is being used. This will literally just have one line in it, the string/number: "2.0"
data.tar.gz: gzipped tar archive contains all of the actual files "belonging" to the package (which for my purposes is none, so this will just be an empty archive - if you want to leave actual scripts or suid binaries on your system as part as your method, those would go here: for example that's where the rootsh package stores its /usr/bin/root and /usr/bin/rootsh scripts).
control.tar.gz: gzipped tar archive contains the stuff used by dpkg/apt/HAM for the package management (which is where we would put our script, along with some text files that fulfill the minimal requirements for a valid .deb package - more on that later)

The first thing I did is set up a temporary working directory inside /tmp, and a subdirectory in that (the main working directory is used to store most generated files, but the sub directory is used as the place from which the .tar.gz files are built (it's the easiest way to make the file paths inside the generated archives work out correctly), then I made the empty data.tar.gz archive by cd'ing into that subfolder and doing "tar -czf" with "./" as the only path to archive.

Then we need to make three required control files for a minimal Debian package: changelog, control, and copyright. These might not all be required for dpkg/apt/HAM to properly install them, but I prefer to generate packages that conform to the Maemo packaging guidelines (which mostly say 'follow the upstream Debian guidelines'). After that, we need to make the actual script file that will be ran when installing the package we generate.

The changelog file contains a record of the changes to the software. Since the actual package is automatically generated, and otherwise has no real 'changes', I just make it have a single 'change' logged, the initial creation (replace "[TIMESTAMP]" with the time printed by running 'date -R' at the moment that the text file was generated):
..note that in both this file and the next one, I use "nobody" as the author/maintainer name, with nobody@example.com as their email. I did this so that it's clear that the package isn't actually maintained by anyone and that it's an automated one. But you could put yourself or something, or whatever makes sense to you here. Also, note that "example.com" is one of the ONLY domain names guaranteed to never be used/registered by the relevant standards, hence why it's safe to use for a not-real address, and except for possibly testing/demos confined to specific local networks, no sane environment should ever be configured to route that domain anywhere. Virtually any other hostname you could make up can someday be registered/routable-to (especially now that arbitrary gTLDs are possible).

The control file contains the meat of the actual '.deb' metadata: this is what tells the underlying packaging system parts what the package name is, what 'section' it goes under, who the maintainer is, etc. With all of the minimally required fields, it looks like this:
..note that the exact section doesn't matter, BUT HAM will only install packages from sections that start with "user/", so we have to pick one of those. I defaulted to "user/admin" because I thought "admin" was the best section choice based on upstream conventions, since for example "sudo" is in the "admin" section and having root access is an administrative thing. But since HAM refuses to install packages with the section "admin", "user/admin" was the next best thing.

Most of the other values can really be whatever (so long as they are still valid for the debian control file specification), but in this example I picked values that make sense and/or are most appropriate relative to Debian+Maemo packaging guidelines, and for the actual package name, I just picked "root" because it's short and sweet and to the point: it provides general ability to run things as root. I initially called it "rootmyself" though, because it was more unique and fit more thematically with what the whole package is about. So, you know, call it whatever you want.

Finally, there needs to be a copyright file, but much like the changelog, it really doesn't matter what you put in it: This is just the copyright which applies to the package itself, and since I'm basically sharing everything needed to generate this package here freely, and it's commonly available knowledge anyway, I figured in my case that just saying it's in the public domain was the best choice:
Okay, so that gets the .deb control-files over with. Then we take the above script from the previous post, or whatever your particular flavor of modify-my-system-to-give-me-root-access you want, and make that our preinst script. You can also use 'postinst', and the result would honestly be virtually the same: as I understand it preinst is ran right before the data.tar.gz is unpacked, and postinst is ran right after that, but since data.tar.gz is empty and the whole point of this package is to just have our script executed by the package manager, it doesn't really matter too much.

So to build the control.tar.gz from the files we've just generated, we want to make the preinst script executable, then we simply tar and gzip those files (control, copyright, changelog, and preinst/postinst) into control.tar.gz. Then we can remove the subdirectory in our working directory, as we won't need it anymore.

Finally, we also create the debian-binary file, which as aforementioned, simply contains the string "2.0".

And now it's time for the fun/key part: manually-build-ar-file process

"ar" format basics:

The ar format is not properly standardized. And there are at least two common variations in it. Also, there are some complex features in it (extended filenames, for example), but luckily we can safely ignore those for our purposes. All we need is the basics.

If you want a deeper understanding, [url=https://en.wikipedia.org/wiki/Ar_(Unix)]Wikipedia[/code] has a pretty good summary (that's where I learned enough to implement this in fkdep last year), but I will cover the details needed for this here:

The file has a header that looks like this (note that there must be a newline character at the end (not really 'shown' here)):
After that each file is basically concatenated into the ar file with some metadata and padding.

"ar" file records:

First, there is a small sub-header for each file. This is basically basic file information (normally we think of this as being inherently linked to the file, but remember the file is just a chunk of data - it's name, ownership, permissions, etc, are actually stored separately on filesystems, so when we're building the 'ar' file from scratch like this we have to manually include it ourselves.

Each field of the subheader has a fixed size, and the various numerical fields are in plaintext (as opposed to binary), mostly base 10, but the mode bits are in base 8, and is padded with trailing spaces up to that size. The fields (and their lengths), followed by the values we want for this use, are:
filename (16 bytes): just the name of the file
Unix timestamp (12 byes): doesn't matter what this is - it's supposed to represent when the file was last modified, which is useful when you're actually archiving files, but for our purposes it doesn't matter when the file looks like it was made. I use the time when we start building the .deb, just because that's more or less 'honest'/accurate.
ID of the user that "owns" the file (6 bytes): "root" user, aka "0" (this is the standard in all .deb files I've ever seen - I don't know/think that it matters what this is, but no point in deviating without a good reason to, I think.)
ID of the group that "owns" the file (6 bytes): "root" group, aka "0" (same reasoning as the ID of the user)
standard UNIX filesystem permission/mode/attribute bits (8 bytes): I set this to 100644, because again, this is what I've seen all .deb files I've inspected.
Size of the file (10 byes): We want this to accurately reflect the size of the file, in bytes, otherwise we'll be making a garbage 'ar' file.

This command composes and appends the entire file subheader string into the deb file we're creating:
Note that the subheader ends with a " ` " character followed by a newline. This is just another 'magic' string/byte-sequence, like the main header: The people who made the file format basically decreed "and lo, thou shalt end the sub-header for each file with the byte sequence 0x60 0x0A" back in the day, and so it is.

After the file's header, the ar file has a strict binary copy of the file, so we just concatenate the contents of the file with the .deb we're making.

Finally, the specification requires that every file record starts on an even byte number, so we check that the SIZE in bytes is odd (SIZE modulo 2 = 1) and if so, then we append one more newline to the file.
So we repeat that for each file that goes in the final ar : debian-binary, control.tar.gz, data.tar.gz.

Once that's done, hard part's over: We've kludged together a .deb file, all from on-board our stock N900.

We finish up by deleting all the intermediate files, and then invoking the dbus command interface provided by HAM to tell HAM to install the shiny new .deb we've made for it. Like so:
Alternatively, you can move the file into /home/user/MyDocs, find it in your file manager (it should have a thin red swirl on a white circle icon - a variation on the Debian logo) and click on it - the file manager will do the same thing to tell HAM to install it behind the scenes.

I recommend deleting your temporary folder and whatever files are left afterwords, but if you're like me and put it in /tmp, then it will be cleared out when you next reboot your phone.

And there you go. We've gained root access on a stock N900 without having to use anything external. Really the only 'hard' part is figuring out the 'ar' format and manually assembling the 'ar'/.deb file.

And here is the entire script I used to do the above, if anyone wanted to see a programmatic specification.

Anyone familiar with my other work might notice that most of this code is yanked right out from the fkdep script I wrote about a year ago, since that's where/when I figured out how to build .deb files using stock-N900-only tools. The key difference is that unlike my normal code (which is usuall 50+% comments), this is 100% code, and devoid of any blank lines, because I just slapped it together for myself.

I use the variable PACKAGE to define the name of the package being made. That way if anyone wants to copy this script directly but wants to change the package name, you only have to change it in one place, and the variable is reused everywhere that's needed.

Nice tutorial!

Just one suggestion:
If you have a pre/postinst script that changes files that do not belong to your package, please also include a pre/postrm script that (optionally) restores their original condition!

I know this can be tricky at times, e.g. when two packages alter the same file but aren't installed/removed in a LIFO manner. But one should at least try by making a simple backup of the files one found during the installation or (maybe) better reversing the sed command.

Not taking care of what happens after your packages are removed usually results in a mess and in my opinion this is one of Maemo's main problems.

Great work and many thanks for providing a much saner approach to gain root access.

This does however highlight that HAM is broken by design and could easily be exploited by an attacker to gain root access using your method. A short term fix might be to identify the setuid executable that is used by HAM to gain root access, remove the setuid bit and then invoke it using the now secure sudo instead.

This also illustrates another of Fremantle's many bad design decisions and another reason why I think the future of the N900 lies with native Debian.

HAM uses /etc/sudoers.d/hildon-application-manager.sudoers, which allows passwordless sudo for apt-worker (as well as for hildon-application-manager-util to handle repositories).

So no setuid here. If you force a password then I suppose HAM will just stop working because sudo will ask for a password without having a terminal for I/O. I suppose we could install some sort of graphical sudo ("gksudo" or whatever) and patch HAM to use it instead of "sudo apt-worker"..

.. just wondering how much effort would be needed to list everything in Maemo (script or executable) that calls sudo.

Once we have that list, we could go one by one sanitizing it (= not assuming that they can get away without a password).

Just download all the source packages and grep them for 'sudo'.
stupid but effective