Re: User Based Init
On Mon, Aug 25, 2003 at 07:00:03PM -0500, Jerry Haltom wrote:
I'm curious how many wtf are you thinking? reactions can be gathered
for the idea of a per-user init.d system?
I see this need a bit, for users who do development with various
services, but admin's not wanting to give them root for one reason or
another. Such as, apache or other web servers. Fetchmail?
(yes I realize fetchmail could be started from cron, which notably also
has a similar per user idea)
/var/lib/user-init/${uid}/init.d
/var/lib/user-init/%{uid}/rc${runlevel}.d
Would be started from /etc/init.d/user-init. Script would run in each
runlevel and run each user's various scripts just like a normal init
sequence, except chuid'd.
So, how insane am I?
Quite :-)
One can't start or stop anything that requires a port under 1024 (such
as apache) without root permissions. You'll have to give them those, no
other option.
You do have the option to go with sudo, however. Sudo allows you to
specify exactly which commands a user may or may not restart; you could
say that a user might run commands of this type:
/etc/init.d/apache .*
some editor /etc/apache/httpd.conf
Watch out for editors, though. Most editors allow you to start shells,
open other files, etc. You'll have to look for one who doesn't.
--
Wouter Verhelst
Debian GNU/Linux -- http://www.debian.org
Nederlandstalige Linux-documentatie -- http://nl.linux.org
Stop breathing down my neck. My breathing is merely a simulation.
So is my neck, stop it anyway!
-- Voyager's EMH versus the Prometheus' EMH, stardate 51462.
pgpsnnNZDgtDs.pgp
Description: PGP signature
Re: User Based Init
Wouter Verhelst [EMAIL PROTECTED] writes: One can't start or stop anything that requires a port under 1024 (such as apache) without root permissions. You'll have to give them those, no other option. Apache doesn't require a port under 1024. By default it is set up to use port 80 på it is quite common to have Apaches bound to some other ports (8000, 8080, being often used). I have often done this as normal user. -- Peter Makholm |One thing you do is prevent good software from [EMAIL PROTECTED] | being written. Who can afford to do professional http://hacking.dk | work for nothing? | -- Bill Gates
Re: User Based Init
On Tue, Aug 26, 2003 at 08:24:10AM +0200, Wouter Verhelst wrote: One can't start or stop anything that requires a port under 1024 (such as apache) without root permissions. You'll have to give them those, no other option. You do have the option to go with sudo, however. Sudo allows you to specify exactly which commands a user may or may not restart; you could say that a user might run commands of this type: /etc/init.d/apache .* some editor /etc/apache/httpd.conf You could use authbind in order to require less privilege for this. -- Colin Watson [EMAIL PROTECTED]
User Based Init
I'm curious how many wtf are you thinking? reactions can be gathered
for the idea of a per-user init.d system?
I see this need a bit, for users who do development with various
services, but admin's not wanting to give them root for one reason or
another. Such as, apache or other web servers. Fetchmail?
(yes I realize fetchmail could be started from cron, which notably also
has a similar per user idea)
/var/lib/user-init/${uid}/init.d
/var/lib/user-init/%{uid}/rc${runlevel}.d
Would be started from /etc/init.d/user-init. Script would run in each
runlevel and run each user's various scripts just like a normal init
sequence, except chuid'd.
So, how insane am I?
This entire idea would consist of essentially one file and a empty
directory. :D
Jerry Haltom
Feedback Plus, Inc.
Re: User Based Init
Oh. :D My bad. :D That definatly counts as a wtf are you thinking! Thanks! On Mon, 2003-08-25 at 19:33, Sam Hocevar wrote: On Mon, Aug 25, 2003, Jerry Haltom wrote: [per-user init scripts] (yes I realize fetchmail could be started from cron, which notably also has a similar per user idea) And it also has a similar at startup idea, see crontab(5).
Re: User Based Init
On Mon, Aug 25, 2003 at 07:00:03PM -0500, Jerry Haltom wrote:
I'm curious how many wtf are you thinking? reactions can be gathered
for the idea of a per-user init.d system?
I see this need a bit, for users who do development with various
services, but admin's not wanting to give them root for one reason or
another. Such as, apache or other web servers. Fetchmail?
(yes I realize fetchmail could be started from cron, which notably also
has a similar per user idea)
/var/lib/user-init/${uid}/init.d
/var/lib/user-init/%{uid}/rc${runlevel}.d
Would be started from /etc/init.d/user-init. Script would run in each
runlevel and run each user's various scripts just like a normal init
sequence, except chuid'd.
How about using @reboot lines in users' crontabs instead?
--
Colin Watson [EMAIL PROTECTED]
Re: User Based Init
On Mon, Aug 25, 2003, Jerry Haltom wrote: [per-user init scripts] (yes I realize fetchmail could be started from cron, which notably also has a similar per user idea) And it also has a similar at startup idea, see crontab(5). -- Sam.
Re: User Based Init
On Tue, 26 Aug 2003 10:00, Jerry Haltom wrote: I'm curious how many wtf are you thinking? reactions can be gathered for the idea of a per-user init.d system? Actually I think that the @reboot option for cron should be extended. There are many situations in which you may want to run per-user scripts, some examples I can think of include: APM events eth0 events (IE PCMCIA insertion/removal or DHCP lease negotiation) libc6 upgrade Arbitary other things as determined by the administrator. I think that we could have cron support @whatever type events, and then when a system program writes whatever to a named pipe that cron maintains it could launch the appropriate jobs. Of course hacking your own scripts to do the same things via sudo is quite possible. However cron has some advantages. Cron already supports mailing the output (and doing it in a secure fashion). Cron supports properly changing the security context (and can easily support doing whatever is necessary for SE Linux and other systems which is better than multiple patches for multiple applications). This also allows the user to edit one file to control everything. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
