expect

expect

[Russell Coker]

I want to run an expect script as:
script program param1 param2 ...

Then have the script spawn "program param1 param2" (sort of like "$@" in a 
bash script).  How do I do this?  Expect wants to combine all the parameters 
into a single parameter that contains spaces. How can I solve this?

Also I want to do it for a varying number of parameters (so having an entry 
for each parameter isn't going to work).

The aim of this is to provide the open_init_pty functionality.  The version I 
posted to the list before will work for the basic SE functionality (IE 
Slackware type support).  But for Debian support (and for full RPM support 
when someone implements it) we need to have open_init_pty run dpkg to install 
packages (and we can install multiple packages at the same time).

-- 
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


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: expect

[Chris Albert]

Russell Coker wrote:

>I want to run an expect script as:
>script program param1 param2 ...
>
>Then have the script spawn "program param1 param2" (sort of like "$@" in a 
>bash script).  How do I do this?  Expect wants to combine all the parameters 
>into a single parameter that contains spaces. How can I solve this?
>
>Also I want to do it for a varying number of parameters (so having an entry 
>for each parameter isn't going to work).
>
>The aim of this is to provide the open_init_pty functionality.  The version I 
>posted to the list before will work for the basic SE functionality (IE 
>Slackware type support).  But for Debian support (and for full RPM support 
>when someone implements it) we need to have open_init_pty run dpkg to install 
>packages (and we can install multiple packages at the same time).
>
>  
>
Russel,
Is is as you woud ex... imagine-- argv.

$expect script param1 param2 ... paramn

All the parameters are found in the list 'argv' , so if in script
...
set argc [llength $argv]
for (set i 0) {$i < $argc} {incr i} {
                puts "arg $i: [lindex $argv  $i]"
}

...

Then the script will spit out:

...

arg 0: param1
arg 1: param2
...
arg n: paramn
...

As in D.Libes' "Exploring Expect" (Oreilly)

Chris




--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: expect

[Russell Coker]

On Sat, 26 Oct 2002 23:32, Chris Albert wrote:
> Russell Coker wrote:
> >I want to run an expect script as:
> >script program param1 param2 ...

OK, I think I didn't make it clear what I want to do.  Say I want to run ls 
with a variety of parameters, I save the following as /tmp/testit:

#!/usr/bin/expect

spawn /bin/ls [lrange $argv 0 end]
interact


Then I type the following command:
/tmp/testit -l -a /tmp

I want the same result as "ls -l -a /tmp" but I don't get it.

-- 
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


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: expect

[Russell Coker]

Excellent!  That's what I need!

On Sun, 27 Oct 2002 01:07, Chris Albert wrote:
> maybe what you want is:
>
> /tmp/testit
> #!/usr/bin/expect
> eval spawn -noecho $argv
>
> And then run:
>
> ./testit.sh ls -a -l /tmp
>
>
> Chris

-- 
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


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: expect

[Stephen D. Smalley]

> Due to what I believe to be bugs in expect, the new open_init_pty program will 
> not work correctly with old versions of expect.  Version 5.38.0 works fine, 
> version 5.32.2 is broken.  I don't know when the bug was fixed exactly.

I've backed out the open_init_pty changes to our internal copy of
run_init.   I'd rather not have the base run_init functionality dependent
on a particular version of expect, and I'm not even sure that it is
wise to depend on having expect installed at all.  

--
Stephen Smalley, NSA
sds@epoch.ncsc.mil


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: expect

[Russell Coker]

On Fri, 29 Nov 2002 21:02, Stephen D. Smalley wrote:
> > Due to what I believe to be bugs in expect, the new open_init_pty program
> > will not work correctly with old versions of expect.  Version 5.38.0
> > works fine, version 5.32.2 is broken.  I don't know when the bug was
> > fixed exactly.
>
> I've backed out the open_init_pty changes to our internal copy of
> run_init.   I'd rather not have the base run_init functionality dependent
> on a particular version of expect, and I'm not even sure that it is
> wise to depend on having expect installed at all.

I will not do the same for my Debian packages.

I can see the benefit in having two options available for users in this case, 
as some smaller devices such as PDAs may not have space for expect.  But 
Debian is a heavy distribution primarily designed for workstations and 
servers.  Debian works well on laptops too but is not designed to scale down 
any further than that.  So I think that there is no reason not to depend on 
expect.

I have made my Debian packages depend on the appropriate version of expect so 
you can just install the packages and be sure that the right things are 
automatically installed.

-- 
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


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: expect

[Jesse Pollard]

On Sunday 01 December 2002 06:08 am, Russell Coker wrote:
> On Fri, 29 Nov 2002 21:02, Stephen D. Smalley wrote:
> > > Due to what I believe to be bugs in expect, the new open_init_pty
> > > program will not work correctly with old versions of expect.  Version
> > > 5.38.0 works fine, version 5.32.2 is broken.  I don't know when the bug
> > > was fixed exactly.
> >
> > I've backed out the open_init_pty changes to our internal copy of
> > run_init.   I'd rather not have the base run_init functionality dependent
> > on a particular version of expect, and I'm not even sure that it is
> > wise to depend on having expect installed at all.
>
> I will not do the same for my Debian packages.
>
> I can see the benefit in having two options available for users in this
> case, as some smaller devices such as PDAs may not have space for expect. 
> But Debian is a heavy distribution primarily designed for workstations and
> servers.  Debian works well on laptops too but is not designed to scale
> down any further than that.  So I think that there is no reason not to
> depend on expect.
>
> I have made my Debian packages depend on the appropriate version of expect
> so you can just install the packages and be sure that the right things are
> automatically installed.

IMHO not the best solution, since the existance of "expect" depends entirely
on local policy. At our site, it is not to be installed without a LOT of
justification first, and only with policy wavers on an individual basis.

Making it mandatory for the system to function would mean that the Debian
distribution will not be permitted. This isn't a major problem for us, at
least, since we have standardized on RH.

-- 
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: expect

[Russell Coker]

I've had a new idea while writing this message and put it at the top.  If 
someone in .gov/.mil can make sure this gets to Steve I'd appreciate it (his 
server doesn't seem to like my server).

Allowing daemons the tty access could probably be addressed in another way.  
If we had a separate role and domain for starting daemons that could be 
entered with newrole (which then removes the need for run_init as the role 
would not have permission to do anything other than restarting daemons) we 
could then allow all daemons read/write/ioctl access to the terminal for it.  
Then if we deny the daemons read access to /dev (wherever possible) and 
/dev/pts (always) then after you exit the shell that newrole ran (relabelling 
your tty) the daemon won't be able to access your tty or open other ttys.

This would also mean that if you have several daemons to restart (EG an LDAP 
error forces me to restart everything that uses LDAP - POP, mail server, 
nscd, etc) you could just type the commands in instead of having to enter 
your password many times.

I believe that this isn't as good as my solution with expect, and it isn't 
something that can be done in a hurry either.

On Mon, 2 Dec 2002 15:09, Jesse Pollard wrote:
> > I have made my Debian packages depend on the appropriate version of
> > expect so you can just install the packages and be sure that the right
> > things are automatically installed.
>
> IMHO not the best solution, since the existance of "expect" depends
> entirely on local policy. At our site, it is not to be installed without a
> LOT of justification first, and only with policy wavers on an individual
> basis.

Expect is in the main section of Debian.  It's a fully supported program, not 
something that has to be separately installed.

Not using expect requires another solution to the problem of daemons wanting 
to write startup messages to terminals.  The CVS policy has no solution to 
this problem, thus in a default install the administrator is UNABLE to 
restart many popular daemons without rebooting the server!!!

The situation in the CVS might be suitable for your use, but it is not 
suitable for the majority of Debian users.  SE Linux is currently not getting 
significant use in Debian because the ratio of effort to result is not 
percieved as being good enough.  Removing expect significantly increases the 
effort and thus makes the situation worse.

In my judgement the solution I have adopted is the best for my use, my 
clients, and every Debian administrator I know.

If you have a better solution then I'd like to hear of it!

Currently IMHO there are two options, what I have done with expect, and 
allowing all daemons read/write access to the administrator tty.

> Making it mandatory for the system to function would mean that the Debian
> distribution will not be permitted. This isn't a major problem for us, at
> least, since we have standardized on RH.

Which means of course there's no reason for me to change on your account.

-- 
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


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: expect

[Tom]

On Mon, Dec 02, 2002 at 03:58:27PM +0100, Russell Coker wrote:
> Allowing daemons the tty access could probably be addressed in another way.  
> If we had a separate role and domain for starting daemons that could be 
> entered with newrole (which then removes the need for run_init as the role 
> would not have permission to do anything other than restarting daemons) we 
> could then allow all daemons read/write/ioctl access to the terminal for it.  
> Then if we deny the daemons read access to /dev (wherever possible) and 
> /dev/pts (always) then after you exit the shell that newrole ran (relabelling 
> your tty) the daemon won't be able to access your tty or open other ttys.


I like this idea a lot. It would make a real-life admin job much, much
easier. It's not just that sometimes you have several daemons to
(re)start, it is during development that you easily restart a given
service a couple dozen times. I know I considered the password request
a nuisance after the 5th or so time.


> I believe that this isn't as good as my solution with expect, and it isn't 
> something that can be done in a hurry either.

Actually, it may turn out to be a better solution, mostly because
expect is no longer required (and a couple of the recent postings here have 
shown just why that may be a good thing).

-- 
PGP/GPG key: http://web.lemuria.org/pubkey.html
pub  1024D/2D7A04F5 2002-05-16 Tom Vogt <tom@lemuria.org>
     Key fingerprint = C731 64D1 4BCF 4C20 48A4  29B2 BF01 9FA1 2D7A 04F5

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: expect

[Russell Coker]

[having a session with the right context to run daemons rather than 
start-stop-daemon for each one]
> I like this idea a lot. It would make a real-life admin job much, much
> easier. It's not just that sometimes you have several daemons to
> (re)start, it is during development that you easily restart a given
> service a couple dozen times. I know I considered the password request
> a nuisance after the 5th or so time.

Good point.  When doing development you tend to have a dozen x-terms open at 
once anyway, so reserving one for starting and stopping daemons should be OK.

Although this is when having labelled X windows would be good.

> > I believe that this isn't as good as my solution with expect, and it
> > isn't something that can be done in a hurry either.
>
> Actually, it may turn out to be a better solution, mostly because
> expect is no longer required (and a couple of the recent postings here have
> shown just why that may be a good thing).

The only real problem we have with expect IMHO is the problem I discovered 
where some daemons don't start because the parent exits too fast.  I expect 
that I'll solve that soon though.

-- 
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


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: expect

[Tom]

On Mon, Dec 02, 2002 at 08:40:26PM +0100, Russell Coker wrote:
> > easier. It's not just that sometimes you have several daemons to
> > (re)start, it is during development that you easily restart a given
> > service a couple dozen times. I know I considered the password request
> > a nuisance after the 5th or so time.
> 
> Good point.  When doing development you tend to have a dozen x-terms open at 
> once anyway, so reserving one for starting and stopping daemons should be OK.
> 
> Although this is when having labelled X windows would be good.

Actually, most of my development work is done remotely, and so I guess
for many other people, so X isn't a factor on the server-side.


> > expect is no longer required (and a couple of the recent postings here have
> > shown just why that may be a good thing).
> 
> The only real problem we have with expect IMHO is the problem I discovered 
> where some daemons don't start because the parent exits too fast.  I expect 
> that I'll solve that soon though.

Actually, it's more a problem of "do I really want Tk on this machine,
just so that I can run SELinx?" - it is a considerably extension of the
dependencies. Maybe I'm too old-school, but I cringe everything I
select a simple packet and it wants to install two dozen libraries and
programming languages in dependencies.
Or maybe that attitude is not for the SELinux world anymore. With a
regular system, the less stuff you have on it the more secure you can
feel (less possibilities for problems). On an SELinux machine, though,
that isn't (or at least shouldn't) be true anymore.


-- 
http://web.lemuria.org/pubkey.html
pub  1024D/2D7A04F5 2002-05-16 Tom Vogt <tom@lemuria.org>
     Key fingerprint = C731 64D1 4BCF 4C20 48A4  29B2 BF01 9FA1 2D7A 04F5

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: expect

[Russell Coker]

On Mon, 2 Dec 2002 23:00, Tom wrote:
> Actually, it's more a problem of "do I really want Tk on this machine,
> just so that I can run SELinx?" - it is a considerably extension of the
> dependencies. Maybe I'm too old-school, but I cringe everything I
> select a simple packet and it wants to install two dozen libraries and
> programming languages in dependencies.

Good point, I've just checked it out, on Debian this involves 3.1M of disk 
space for Expect and TK.  It hadn't been an issue for me as I already had 
other packages depending on TK on all my machines.

Maybe I'll have to go back to writeing such a program in C...

> Or maybe that attitude is not for the SELinux world anymore. With a
> regular system, the less stuff you have on it the more secure you can
> feel (less possibilities for problems). On an SELinux machine, though,
> that isn't (or at least shouldn't) be true anymore.

I don't think that having expect present causes any security problems anyway.

-- 
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


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

expect

[Russell Coker]

Due to what I believe to be bugs in expect, the new open_init_pty program will 
not work correctly with old versions of expect.  Version 5.38.0 works fine, 
version 5.32.2 is broken.  I don't know when the bug was fixed exactly.

-- 
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


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

expect

[Russell Coker]

[-- Attachment #1: Type: text/plain, Size: 474 bytes --]

I've attached a bug report I filed against expect.  This causes annoying avc 
messages about fd use if you have expect running a process in a different 
security context where it can't write to the controlling terminal.

-- 
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

[-- Attachment #2: bug --]
[-- Type: text/x-diff, Size: 2026 bytes --]

Subject: expect: leaves file handle 3 open when running programs
Package: expect
Version: 5.38.0-2
Severity: normal

When expect opens the new stdin/out/err handles from the pseudo tty it creates
it will first dup2 the stderr file handle to file handle 3 so it can report
errors directly to the controlling terminal.

However it does not set this file handle to close on exec (NB setting file
handle 3 to close on exec after doing dup2(2, 3) has no affect on file handle
2).  This means that the child process will have file handle 3 unexpectedly
open.  Among other things the child process could use this file handle to
detect the presence of expect and to send back data to the terminal directly
without expect controlling it.

Here is a patch to fix this.

diff -ru expect-orig/exp_clib.c expect-5.38.0/exp_clib.c
--- expect-orig/exp_clib.c	2002-03-23 05:55:04.000000000 +0100
+++ expect-5.38.0/exp_clib.c	2002-10-27 20:23:15.000000000 +0100
@@ -2500,6 +2500,7 @@
 
 	/* save error fd while we're setting up new one */
 	errorfd = fcntl(2,F_DUPFD,3);
+	fcntl(3, F_SETFD, FD_CLOEXEC);
 	/* and here is the macro to restore it */
 #define restore_error_fd {close(2);fcntl(errorfd,F_DUPFD,2);}
 
diff -ru expect-orig/exp_command.c expect-5.38.0/exp_command.c
--- expect-orig/exp_command.c	2002-10-27 19:52:06.000000000 +0100
+++ expect-5.38.0/exp_command.c	2002-10-27 20:36:55.000000000 +0100
@@ -1036,6 +1036,7 @@
 
 	/* save error fd while we're setting up new one */
 	errorfd = fcntl(2,F_DUPFD,3);
+	fcntl(3, F_SETFD, FD_CLOEXEC);
 	/* and here is the macro to restore it */
 #define restore_error_fd {close(2);fcntl(errorfd,F_DUPFD,2);}
 

-- System Information
Debian Release: testing/unstable
Kernel Version: Linux lyta 2.4.19lsm #1 Wed Sep 25 15:49:15 CEST 2002 i686 Pentium III (Coppermine) GenuineIntel GNU/Linux

Versions of the packages expect depends on:
ii  libc6          2.3.1-3        GNU C Library: Shared libraries and Timezone
ii  tcl8.3         8.3.3-8        The Tool Command Language (TCL) v8.3 - Run-T

Expect

[Dean Takemori]

I've been having problems with the expect package, which is part
of the tcltk distribution.  The problem is essentially the TIOCSCTTY
error as reported below from the Expect FAQ.  [Note, not all expect
scripts have this problem, just the ones that allocate ptys.
Unfortunately, this means most (all?) dejanew tests fail.]

I am working with a R4 system, upgraded to egcs-1.1.1-1c,
binutils-2.9.1-19b and glibc-0.961212-1o.

The rest of the tcltk package (tcl-8.0.3-20b, tk-8.0.3-20b,
tix-4.1.0.6-20b and tclx-8.0.3-20b) all compile and install
and test ok.  Expect 5.25, 5.26 and 5.28 all fail.

The FAQ entries quoted below suggest that maybe this is the old
glibc 1.99 != 2 problem in another form

Anyone have any ideas?

>From the Expect 5.28 FAQ:
>#52. Why does Expect fail on RedHat 5.0?
>
>Lots of people have reported the following error from Expect on
>RedHat 5.0:
>
>failed to get controlling terminal using TIOCSCTTY
>parent sync byte write: broken pipe
> 
>Martin Bly <ussc@star.rl.ac.uk> reports that:
> 
>The fault is/was in the GNU libc (aka glibc) provided by Red Hat
>Software.  Our sysadmin updated the version of the C libraries we have
>installed and both problems have vanished - in the case of the expect
>test, without a rebuild.
>======================================================================
> 
>#53. Why does Expect fail on RedHat 5.1?
> 
>People have reported the following error from Expect on RedHat
>5.1:
> 
>failed to get controlling terminal using TIOCSCTTY
>parent sync byte write: broken pipe
> 
>If there are any people
>who have some debugging experience and can reproduce that error on
>RedHat 5.1, read on:
> 
>First look in the man page (or perhaps diff the 5.1 and pre-5.1 man
>pages) governing TIOCSTTY and let me know what you find.
>Alternatively look at the source to xterm (or some other program that
>must allocate a pty) and see how it is allocating a pty.


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]