root on ports

Bryan Dumm bdumm at
Thu Feb 15 06:36:21 PST 2001

On Thursday 15 February 2001 14:10, you wrote:
> On Thu, Feb 15, 2001 at 07:58:26AM +0000, Bryan Dumm wrote:
> > k, but where is the pass????
> >
> > Or are you saying
> >
> > <password>gjfkjreitu8</password>
> > stuff
> > later on
> > <make_install user="root">
> No, I don't think that putting a password in the profile is a good idea.
> Well, if we send the profile through some encrypted channel or something,
> then I guess it's ok.
> But I prefer sending it separately, before we even start talking with
> the backend. Could be part of some initial 5-way handshake. ;)
> All this must be carefully thought, we are entering the dangerous zone ...

/me must be a real dangerous person then.....

Umm I think we are confusing things here...

elements like <make_install> need to be root, right?

so that alfs process has to become root @ some point, right?

<password>does not have plain text here</password>

and furthermore, I think the alfs_app designer, can decide 
if they are going to send it by ssl or whatever. Heck they could
even add their own wrappers around the profile or <password>
that are decrypted on either side. This is something lots of web
designers do quite often, really. And if your paranoid, you can
get real paranoid 8-)

if we did the 

      later on in profile
    <make_install user="root">

Then password could be added to the alfs_app while the 
profile ran. When it ran into those <make_install user="root">
elements, the make_install handler would look to see if $password
had been define in alfs_app and if so make the su or whatever 
call to do the make_install.... 

Each handler that needed root could use this scheme?

If someone has a better idea of how to not have root on the port,
and provide some way for a root process to be processed by alfs,
please explain. :)


More information about the alfs-discuss mailing list