[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.