nsenum wayfwxec

November 22, 2004

sudoscript 2.1.2 Released

Only one day later than promised, sudoscript 2.1.2 has been released. This update fixes a moderately severe security bug as detailed below, and adds a nifty "ss -" feature, like "su -". Download it from the download page.

Posted by hbo at 09:12 PM | Comments (0)

November 14, 2004

Sudoscript 2.1.2 beta 1 Released

This point release features a new "-" switch to ss (like "su -") and three bug fixes, one of which is a moderately severe security bug.


The security bug only bites if you are enabling non-root access with sudoscript. But if you are, any member of the ssers group can send a SIGHUP signal to any process. Although this release is labled "beta," the changes are small. If you are in the class of users noted, you probably should upgrade right away. I'm going to leave the beta out there for just a week before going to an official release, assuming that no problems show up.


Longer term, I'm working on the session replay stuff, and thinking about rearchitecting the IPC mechanisms. This latter has been prompted by a bug report and patch from Conrad Link, among three he submitted, that pointed out the SIGHUP vulnerability. Conrad has some ideas on how to make the back-end more secure, which I'd like to mull over a bit before deciding how to proceed.

Posted by hbo at 05:19 PM | Comments (0)

June 06, 2004

Displaying script(1) Logs

In my sudoscript entry in BSD Hacks, I discuss the possibility of snipping a vi session out of sudoscript log and cating it to the screen to visualize it. This only works if you use the same terminal emulator as the sudoscript user, and if your terminal is sized the same. I reread the entry when the book came out recenty, and it piqued my interest in developing software to make the process easier. My first crack at a script to list and replay sudoscript sessions is here. The script has several weaknesses, most stemming from the fact that it's just a quick hack. For example, there's no spanning of log files, and if the session you are interested in is not in the file you choose, then you won't see it at all. One drawback that can't be hacked around though is the coarse (1s) resolution of the timestamps in the sudoscript logs, and the fact that even those timestamps reflect when the line-blocked output hit the logging daemon, not when the character-blocked output occurred in script(1). Even so, the script is useful, as long as your terminal emulator and settings match the user's.

Digging into the timing issue, I flirted with using Time::HiRes to write better logs. But the line blocking is still unavoidable. Also, I hate to make my portable code depend on modules that aren't in the Perl standard library (Time::HiRes was added in 5.8.0). Speaking of unportable solutions, the script(1) that comes with util-linux has this nifty feature:

  -t      Output timeing data to standard error. This data contains 
          two fields, separated by a space. The first field indicates 
          how much time elapsed since the previous output. The second 
          field indicates how many characters were output this time. 
          This information can be used to replay typescripts with 
          realistic typing and output delays.

This is cool! The script program is in the best position to know exactly when characters were typed and displayed. On Linux, script helpfuly provides this information. A script to replay sessions from a typescript and timing files is here. Run linux script(1) like this:

   script -f -t 2>times

Do some fullscreen stuff. Run vi, top or whatever. Exit script and run replay in the same directory. It works really well!

Integrating this into sudoscript would be tough. If ss finds it is running on Linux, it would have to redirect script's stderr as above to a per-session timings file. Later, an adapted replay script could snip the sessions out of the log files and write them to a temporarily reconstituted typescript. This would have to be exactly like what would have been written if the output hadn't gone to the daemon. (Of course, I could just write the typescript directly, but the daemons do a fair amount of useful work besides writing the logs.) Managing these files would be interesting. When a log drops off the end of the rotation, the corresponding timings file(s) should be deleted to.

Add in the unportability of this approah, and I'm more inclined to go with the less than perfect, but perhaps good enough first solution.

Update: The script from util-linux builds and runs on OpenBSD. The portability issue is only with systems that use SysV PTYs. At least, the build honks loudly on Solaris 9. I assume that HP-UX, AIX and Irix would have similar problems. If four of the platforms I support can run this modified script(1), then I'm somewhst more willing to look at implementing it.

Posted by hbo at 12:53 PM | Comments (0)

June 05, 2004

User Environment

The idea and fix I got the other day was from Rich Amik. He got the following error when trying to start ss with the -u switch:

ss –u <user>
Script started, file is <FIFO>
bash: /home/<calling user>/.bashrc: Permission denied

This was because the -u user had no exec (or perhaps, read) permissions on the calling user's .bashrc. This can happen with root, too, if the calling user's home directory is on an NFS file system exported with root mapped to nobody. Rich's suggested solution was to set the HOME environment variable to the -u user's home after ss had become that user, but before the script command was run. This worked.

Rich also asked a question that had come up before. How come the resulting shell had the environment of the calling user? My answer to this had always been that the script command ran the shell, not ss, and that I therefore had no control over the resulting environment. I was about to give Rich this answer, but then I looked again at his reported error message. The shell was attempting to run ${HOME}/.bashrc! Blinding Flash of the Obvious. Setting HOME to the target user's home before running script would cause the shell to run that user's shell startup script(s), at least for bash, so that the resulting shell would have the target user's environment.

I quickly hacked together code to make ss set $ENV{HOME} in perl at the correct place. I added a new switch to ss, '-', as in 'su -'. It does the trick, and will become part of the upcoming release. If you can't wait, a patch to sudoshell to enable this feature is here.

Posted by hbo at 10:27 AM

June 03, 2004

New SIte!

Welcome to the new sudoscript web site! Since I broke down and bought Moveable Type 3.0D for Anger Management, and since BSD Hacks was just published, engendering a lot of new interest, I decided to convert the site over to a blog.

For now it's the same old content with the default MT3.0D style. (Actually, it's very slightly tweaked from the default.) But soon there will be a new release of sudoscript. I'm sure I'll play with the design of the web site some more as I go along. I also plan to do my sudoscript design work here in public. It would be cool to have participation from users here too. I get my best ideas for the software from users who email me with questions or comments. In fact, the idea for a feature in the upcoming release came to me in just that way earlier today. A user noticed a problem and designed a solution. It turns out his solution solved another problem he asked about! (It's so funny. I noticed he'd aready solved his second problem by looking at the error from his first one.) More about this soon.

Posted by hbo at 09:09 PM | Comments (0)