Designing a new init: low level communication

a-aa a-aa at hollowtube.mine.nu
Mon Aug 29 12:47:53 UTC 2005


Erich Schubert wrote:

>Hi,
>  
>
>>You can use /dev, which means it's accessable from very early in the
>>boot, initng does this and it works well.  Also, are we sure this needs
>>a writable filesystem?  I think if the socket exists it might not, I
>>can't really remember ;)
>>    
>>
>
>That only works with FIFOs IIRC - sockets will disappear when closed,
>so they only live for the runtime of the program. I don't know if
>they'll actually get a node on the disk.
>Where I'm skeptical with /dev is with static/udev/devfs.
>You would need to ensure that the fifos "survive" the udev mounting.
>For FIFOs I'd suggest the location /lib/debinit/fifoo
>Since /lib also needs to be accessible early on, and the fifo is
>somewhat static.
>
>  
>
>>I have a bit of experience here, as initng has been trying out a few
>>here, fifo's were horrible and unix sockets worked very well, and we can
>>solve issues here either with initramfs on boot or by waiting until /dev
>>is mounted (which by initng is after the first script is launched).
>>    
>>
>
>Hmm... kind of a hack to require the first script to make /dev
>writeable... but that sure would be a way we could take. Then we could
>use socket semantics.
>I've worked with fifos - on minit - and they were okay, the biggest
>issue is that they occasionally are locked (so you need to retry) and
>that you can't use them for having a monitor (e.g. the dbus
>connector). We sure could use sockets for the dbus connector later on.
>Can anyone comment on the following: "Connecting  to  the
>       socket  object  requires  read/write permission.  This behavior differs
>       from many BSD-derived systems which ignore permissions for  Unix  sock-
>       ets. Portable programs should not rely on this feature for security."
>And wheter we can work around that by placing the sockets into a
>restricted directory?
>  
>
You can, just make sure the directory has the right permissions and it's
not a problem.

>  
>
>>How much do we want to support remotly though?  Do we want a plugin api
>>or a comunication api?  I imagine a comunication api would end up being
>>considerably more advanced and a lot harder to implement, but that could
>>be because I'm used to working with plugins ;)
>>    
>>
>
>I'm not sure about that. If we keep the messages to a minimum, it's
>just about writing some structs to a fd. Not really difficult.
>
>I'd like to have a statically linked init, since on a platform I'm
>working on there is no dynamic linking available.
>
>Also I think we are going to need this anyway, because I do not want
>the dbus connector to be in init itself.
>  
>
How would you handle stuff like suid/nice/chroot/chdir/optional "extra"
stuff that can't really be done remotly?  Put all of it in defines in
the core?

>best regards,
>Erich Schubert
>--
>    erich@(mucl.de|debian.org)      --      GPG Key ID: 4B3A135C    (o_
>  To understand recursion you first need to understand recursion.   //\
>  Wo befreundete Wege zusammenlaufen, da sieht die ganze Welt für   V_/_
>        eine Stunde wie eine Heimat aus. --- Herrmann Hesse
>
>_______________________________________________
>initscripts-ng-devel mailing list
>initscripts-ng-devel at lists.alioth.debian.org
>http://lists.alioth.debian.org/mailman/listinfo/initscripts-ng-devel
>
>  
>




More information about the initscripts-ng-devel mailing list