Re: Great SWT Program

On Dec 16, 3:08 pm, blm...@xxxxxxxxxxxxx <blm...@xxxxxxxxxxxxx> wrote:
Well, *I* did, but I was under the impression that a lot of the
tools you seem to like have a notion of "file association" based
on file extensions, which to me suggests that they infer file type
from file extension. No?

The powerful ones let you manually specify file types in case they get
it wrong. Then there are cases like .avi where there's a bunch of
possible internal formats to use, such as divx, and the tool needs to
know which to use for an output file (though it can detect the format
of a pre-existing file). There's right-click "open with..." in the
shell, too. Better paint programs provide the ability to set various
fiddly options for the exact encoding behavior to use when outputting
gif, jpeg, and png images. And so forth.

Unless there IS a way to specify just the output extension and convert
then reuses the input file names in filling out the names of the
output files. But you'd implied that there is not and the output file
name has to be fully and separately specified.

Well, I can't speak for Bent, but if I wanted to do something like
this, I'd use a shell for loop, something like this:

[snip "solution" unusable by non-programmers]

Well, I suppose you could telnet into your own machine or something
from a terminal emulator and log in as root there. But then you're
stuck in text mode for all of them privileged commands and can't use
nice *graphical* tools as superuser. Also seems a bit hackish.

s/telnet/ssh/, and I suspect that this is what is done by many
people who want to be able to switch back and forth between doing
something as the superuser and doing something as a regular user.

The exact protocol used is, of course, irrelevant to my point here.
(Besides, there's also "rlogin". :))

I'm not sure the additional security of ssh (as compared to telnet)
matters much in this scenario

Not if you're behind a NAT and don't forward the telnet port. If
telnetd's as safe as sshd when exposed on the internet, then not at
all since the only security benefit then is password (and maybe full-
session) encryption but the session can't be sniffed when none of the
packets involved leaves the one machine.

but the "-X" option of ssh means that one can run graphical applications.

I thought you folks hated to run graphical applications over wire
protocols?

Then again, I just tried simply su'ing to root in a terminal-emulator
window and starting a graphical program, and that worked too, though
I seem to remember it *not* working in the past. Huh.

Eh?

A risk here is that the terminal-emulator window with the
root session might not be easy to distinguish from other
terminal-emulator windows -- the shell prompts would probably be
different, but that might be easy to not spot.

Interesting how modal information being subtle enough to be easy to
not spot suddenly becomes a concern of yours when security is at
issue, even when it isn't when novice user friendliness is all that's
at issue and the worst that can happen is that some n00b accidentally
repartitions her hard drive when she meant to launch the music player
app to listen to Britney screech for an hour. :P

So, too-subtle cues in a tunnel-vision-inducing UI that increase the
risk of gunshot wounds seem to fall into two categories:
* Ones that greatly increase the risk of someone else shooting
you: Bad.
* Ones that greatly increase the risk of a self-inflicted
gunshot wound to the foot: Good. Keeps you on your toes
and keeps out the riffraff too.

This observation gives one some *very* interesting insights into the
psychology of "elite" unix users...:)

(Incidentally, I'm not sure which punishment better fits the crime of
launching a media player with intent to play Britney: data trashage,
or actually hearing Britney screech for an hour as intended. Perhaps
the latter is too harsh...I'd say it depends on whether there would be
innocent bystanders in earshot and whether you are using headphones
not turned up too high.)

I seem to remember
coming across a suggestion in another newsgroup recently that
one could use different background colors (root versus non-root)
to help make the distinction clearer.

Wouldn't be surprised if you could hack it to do that somehow.

I do recall seeing some system with windows open on a non-Windows GUI
desktop. Some of them said "Konsole" but one said "Root Console", but
they weren't otherwise all that distinguishable. There were also non-
terminal-emulator windows open, including one that looked suspiciously
like Minesweeper. :)

Some of the "nice graphical tools" for sysadmin-type tasks now
prompt for the root password when run by a regular user.

Instead of just not working -- yeah, that makes sense. I wonder how
well they protected it from privilege escalation, though. I can
imagine a few issues:

* Password visible in memory in an area shared among X
applications: possibly sniffable by an unprivileged logged-on
user able to run arbitrary code linked against common X
libraries.
* Something's gotta run suid root.

The latter can be risk-minimized by architecture: the GUI app is non-
suid and invokes a small, suid-root utility to do the "dirty work".
Perhaps it simply launches a command interpreter that logs in as root
and runs a script. The script, suid-root utility, or whatever would
obviously need to not be writable by anyone but root. The script
method has the advantage that the script does not even need to be
world-readable, only root-readable. Regardless, it would need to be
divided into two executables, one that does nearly everything and is
not privileged, and one that is privileged and as narrow and
specialized as possible and is puppeted by the other. The other needs
to be designed to be incapable of running the privileged bit at all
without seeing root credentials, of course, and still may be subject
to a confused-deputy exploit, depending. The script method has an
advantage here also: the puppet can prompt for a password if it needs
to run the script to do something, and simply pass this password
verbatim to the login for the as-other-user-command-interpreter spawn.
If the password is wrong, the command interpreter with root privileges
never runs, and the script therefore never runs with root privileges.

I don't know how to deal with the former. The system's robust memory
protection probably helps. If there are shared address spaces, shared
memory buffers used by shared library code, and the like in the
implementation of X, then the password and any other privileged
information need to be kept out of those, at least unless encryption
is employed. I guess there's some architecture in place for secure
internal handling of credentials when using graphical login tools and
the like that can be used here, and more generally for using
privileged information in interprocess communication on unix, to
safeguard against other users sniffing this data.

Once again [incorrect offtopic insulting speculations about
me deleted]

None of the nasty things that you have said or implied about me are at
all true.
.