Adding System Level Accounts from chroot-ed Apache?

roadoi asks: "I have a Web server which is running RHLinux 6.0 and Apache 1.3.9+PHP 3.0.12 in a chrooted environment. This machine also runs an ftp server which authenticates off of the main /etc/passwd file. I want to have the ability to add system level accounts from the Web server (by running a script, etc.) and have accounts added to the main /etc/passwd file rather than the cut down /etc/passwd file lying within the chroot environment. Accounts should be active immediately so polling a database or the like at regular intervals is out of the question. Is this at all possible?" I see why polling some file would be such a bad idea, but maybe some kind of solution could be arranged where a daemon could be set to watch a port for account data. This opens up very large can of worms, however and is probably not the best option. Does anyone have any better solutions?

Re:Batch

[Clifton Wood]

Yes, but that would be the same as polling a database at specific intervals, which roadoi (the person who submitted this topic) said he did not want to do. Personally, your approach would be a similar approach to what I would do, however there may be more to the situation that makes such undesirable. I hope roadoi comes online and gives us some reasons as to why polling is undesirable in this case as cron and such were made for things like this.

Batch

[Jethro]

Another way you can do it (and I'm not saying anything about how secure this is or isn't!), is have your script create a data file containing information in a predefined format, like:

ADD:jsmith:John Smith

and have a cron job run every 5/10/whatever minutes and process this file. That's how we used to do user additions at the ISP I used to work for, except that the file was generated by some database and placed on FTP.

You can have a your 'real' program rename the file right away and do some lockfile tricks to make sure the two processes don't kill each other off.



--

Hard link? Or Maybe..

[hoss10]

If it doesn't like:
ln /etc/passwd /webserverdir/etc/passwd

what about:
mv /etc/passwd /webserverdir/etc
ln /webserverdir/etc/passwd /etc/passwd

If you see what I mean!
I was always wondering about what exactly was the status of a hardlinked file (is it truly ambiguous as to what dir it is in - or is one of the links a "real" one)

Would a soft link from /etc to the /webserverdir work? Ie. does the login stuff insist that /etc/passwd be a real file?

------------------------------------------------ -
"If I can shoot rabbits then I can shoot fascists" -

How odd.

[NetBoy]

I'm curious as to why someone would run
a chrooted web server just to turn around
and try to dig out of the chroot jail for
the purpose of adding system accounts.

I suppose if I had to do something like that
I'd use some sort of network authentication
and appropriate PAM modules with mysql
instead of flat file.

Or change the chroot to /.

but why?

[mikeee]

Umm... the whole point of running in a chrooted environment is to insulate security on the web server from the security of the system. If you're punching a hole in that barrier, why bother chrooting at all?

local IPC

[The Pim]

If you flatly reject all IPC (inter-process communication) as "a can of worms", you're probably stuck. But IPC can be done properly, and is very powerful. A daemon listening on a unix domain socket can reliably verify the identity of the other end of the socket (via the kernel), perform strict and careful validation on the input, and carefully update the user database.

Re:Hard link?

[justharv]

Hard links will only work on the same filesystem. mv'ing passwd and then hard linking back to /etc is pretty much redundant.

Hard link?

[Coward, Anonymous]

I haven't tried it, but I'd think that creating a hard link to /etc/passwd should work.

This is not a good idea

[pdlug]

Adding system level accounts in this way is a bad idea, it's insecure and if the program is not written carefully you can hose your passwd file. I would reccommend having it add users to a database or datafile. For ftp server authentication switch to a server like proftpd which has support for a variety of authentication types (and if it's not support it's easy to hack in since they have a module architecture that is clean and easy to work with). Or perhaps the ftp server can be forced through a configuration option to use a passwd file other than /etc/passwd, this might work out quite well.