About the only thing that is guaranteed to be (somewhat) the same on all Linux installations is the kernel, because the kernel is what makes it Linux.
The kernel has a command line parameter init which specifies the path and name of the binary which is responsible for bootstrapping the userspace environment after the kernel initialization is complete. Normally /sbin/init is used for that purpose, however it can be replaced with any other binary you like which (along with required libraries, configuration files, etc.) is available on the root file system.
However, that's probably not what you want.
Pretty much everything you do beyond that is going to, in some way, depend on the behavior of the installed software. There is not even any guarantee that the init binary will live at /sbin/init.
Most software that faces this problem works around it by providing several possible init configurations, and have an installation script (or has the administrator) pick the one appropriate to the system in question; if no appropriate configuration is provided, the administrator is expected to write up their own.
Unfortunately, this is the downside of the versatility that most Linux distributions provide. In Windows there is only one way to do it (well, there are a few, but they are specifically defined by Microsoft and you can't really do anything to change them even as a programmer-competent administrator).
The problems stem from not wanting to run as root (I want the files generated to be user-accessible)
If that was your only problem, however, the easy solution would be to simply change ownership of the file immediately after creating it. Or, do what most daemons do: start as root, then drop privileges and switch to an unprivileged account after doing whatever initialization needs to be done as root (for example, opening sockets to listen to privileged ports, read protected configuration files into memory, etc.).
I imagine the logged in user could be programmatically determined, but you'd need to be a lot more specific then about what exactly you mean by 'logged in user'. Detecting which user account(s) (if any) is/are running a particular binary is fairly trivial by scanning the process tree, and just might get you close enough to what you are trying to achieve. Once you know which user account to target, you can either switch your security context to that account, or launch a separate process as that user (similar to how sudo does its grunt work).
Your service (or the shipped startup method) is responsible for dropping its rights. This is easily accomplished. Still, there is no universal solution. You’ll simply have to accommodate all start-up methods. Running on boot is probably not ideal if it’s a per-session service. – Daniel B – 2014-06-03T21:32:00.783
What broke with init.d (or better said SysV init)? Use su to run the program under another user e.g.
– Cristian Ciupitu – 2014-06-03T21:34:29.330su - joe /usr/local/bin/stupidprogram.1No, there is far too much variety in Linux based systems for their to be one way to do this. – Zoredache – 2014-06-03T21:34:36.957
1Could you clarify the exact use case? This sounds very dodgy, looks like you're trying to install a persistent Linux malware on PoS machines you have no control over but somehow got root on, that reads its instructions from a file dropped by a userland process.. But maybe I'm just paranoid :) – lorenzog – 2014-06-04T07:21:04.953
@lorenzog, yes it is indeed very similar. but what do you do when the software you have to monitor isn't yours, nor can be bothered? – Yan – 2014-06-04T12:19:36.647
@Cristian: the problem is reliably discovering the current user – Yan – 2014-06-04T12:21:08.713
@Zoredach: yes, a simple task, nigh impossible. also, much of the information points the wrong way. that is why I had to bid this question. – Yan – 2014-06-04T12:35:24.410
@Yan, define current user and how he/she logins. – Cristian Ciupitu – 2014-06-04T13:00:25.713
@Yan I wasn't arguing on the validity of the question :) indeed the use of Daemon Tools suggested below is the best solution if your systems have
/etc/inittab. Daemontools compile on all UNIXes, most don't even require a restart to get running. – lorenzog – 2014-06-04T13:09:34.307