1237e12b6c09
tech



Hello Pascal - 

CA>> Apparently there are security issues at stake as well
CA>> according to what I find for "automount"? 

PS> No idea, I don't use automounting. 

I need to research this 'automount' and others like it. I
really don't trust myself to not forget to do the 'umount'. I
tend to be a bit obsessive while programming and/or tweaking
with unpleasant results at times. :-\ 

CA>> Just a newbie here but doesn't *nix require that you
CA>> address the proper device (dev) in this scenario? 

PS> Yes, you need to pass the right name to open(), but you
PS> don't need different open() functions for different
PS> devices. If you open /dev/dsp, your output will go the
PS> soundcard when you use write(), if you open /dev/lp0, your
PS> output will go to the first printer port. 

OK, so there is some learning involved to memorize what 'dev'
you need to be addressing and when. 

PS> Under other operating system, you often have to use very
PS> different sound_open() and printer_open() functions which
PS> get different parameters that you all need to learn. Huge
PS> burden on the programmer - and humans being what they are
PS> (myself not excluded), people tend to confuse stuff when
PS> there are two different ways for doing what is essentially
PS> the same thing (preparing to send some data to some device). 

I have serious problems with code that is very similar but
different such as using AWK for awhile then back to C then back
to AWK. They are just enough alike to make remembering the
_exact_ syntax difficult (for me). 

CA>> Depends on the level of involvement. Users who only want
CA>> to browse the Internet and send/receive email don't need
CA>> to tweak the OS nor understand a great deal to become
CA>> successful. 

PS> Granted, but that needs proper measures taken by the OS.
PS> The default configs of Internet explorer and Outlook are
PS> unsafe and an invitation to virus/worm writers. If they
PS> were secure, no problem. 

Outlook is such a mess the first thing I did was archive the
entire Outlook directory so that no other app could 'call'
Outlook for _any_ reason. IEx is a bit more difficult to just
ignore. Webpages must be functional when using IEx v4 or better
since it has a huge proportion of the total Internet users
using it (one version or another). I depend on my ZoneAlarm
install and popup blocking software plus I have altered
permissions for ActiveX that prevent simple exploits at least.
:-\ 

CA>> I wouldn't remove 'cp', I would just hide it from casual
CA>> users and replace it with a more intelligent version. ;-) 

PS> Could be done. I'm hoping all the GUI file manager stuff
PS> that newbies nowadays probably use does have safeguards in
PS> place. I have cp aliased on my system to "cp -i" so that it
PS> asks before overwriting anything. ;) 

Good example. :-) 

That should be the default 'mode' for the binary with an
override if you don't want prompting IMO. ;-) 

CA>> If that 'user' is an employee it could be an expensive
CA>> lesson. I still think work needs to be done to prevent
some of this from happening at a desktop terminal. 

PS> In that scenario, you would probably have an experienced
PS> admin in place and then you can indeed force a different rm
PS> (and others) binary upon users so that they can't wreak too
PS> much havoc. Of course you would have backups and if it's
PS> really critical data, you wouldn't give the user the
PS> opportunity to run any program he or she likes. 

If sys admin was my 'career' move I would learn to modify the
code for the more potentially damaging utilities to, as you
have, prompt before overwriting/deleting/etc. and recomple them
then remove the 'standard' versions from the machines. 

CA>> I've not had access to a full Linux install as yet but
CA>> using mini-installs I find it necessary to be logged in as
CA>> 'root' to install software that I have downloaded. 

PS> On full distributions, there are GUI tools for doing that. 

I'm just guessing here but the GUI can't 'promote' itself to
'root' which means the user would have to login as 'root' to
use the GUI, Y/N? 

CA>> If this is typical then all home users of Linux face this
CA>> same dilemma that 'ready or not' they must be 'root' at
CA>> times to get the system where they want it to be with all
packages they require. 

PS> Yes, but installation is usually not that risky. Package
PS> managers do prevent overwriting of important system files
PS> or installation of packages that conflict with already
PS> installed packages. 

I wish Windows installs had thought of that years ago. I've had
to create a script to archive DLLs, drivers, etc. prior to a
new install just to prevent overwriting needed ones when
installing third party apps or utilities. :-\ 

CA>> What I've been reading lately tells me that even burning
CA>> image copies to CDs is not foolproof indefinitely. I don't
CA>> see as much effort being put into securing copies beyond a
CA>> few years and that worries me. Data can be useful for more
CA>> than a few years and my source code is valuable (to me) as
a reference if nothing else. 

PS> I personally use an MO drive where the discs are supposed
PS> to last (even guaranteed) for 10 years or more. I also have
PS> copies on hard disk, of course. So the MO backups are
PS> useful when a hard disk fails me, and the hard disk copies
PS> in case my backup gets lost and I need to recreate it. It's
PS> very unlikely for both of them to fail at the same time and
PS> I have three sets of full (weekly) backups anyway. At most
PS> I can loose a week worth of work. 

You are fortunate to have the MO drive. Most of us don't. :-\ 

If they can't develop something that lasts longer for home
users I am hoping someone will setup a business to create a
more permanent copy of files on some form of media even if I
have to pay them to do it _for_ me. :-\ 

PS> [...] 

CA>> I waited about 2 months before trying (and succeeding) the
CA>> third time. I was so angry I couldn't focus on the program
CA>> anymore. 

PS> I sometimes did similar things when I lost some program
PS> important to me in a hard disk crash or just by not
PS> thinking before repartitioning a disk. It gets really
PS> annoying once you have to rewrite stuff a third time... and
PS> it never is 100% the same as before. 

The 'never the same as before' has worked to my advantage, at
times, with an ever better finished product but not often
enough to compensate for the stress. 

CA>> I have printouts of software I wrote on an APPLE that are
CA>> past yellow moving to brown and are becoming brittle. If
CA>> you live long enough you eventually lose everything it
CA>> seems. :-\ 

PS> I have a few printouts from my DOS days, but none of the
PS> first stuff I did on my C64. :( 

There were so many proprietary ROM code accesses in early PC
programs that getting most to work again would be difficult
now. On the CoCo I could temporarilly double the CPU speed when
necessary. I did find a way to do this on Intel hardware in ASM
but only recently and only for DOS. :-) 

CA>> I have no problem with access at low levels. I just don't
CA>> think it is for everyone and Linux needs to be 'everyone
CA>> friendly' to become a viable desktop OS. 

PS> I think stuff like a Mandrake, SuSE, Red Hat, or whatever,
PS> default install is quite safe to use without much risk of
PS> accidentally breaking the system. Can't say for certain
PS> since I'm not a typical desktop user. ;) 

Allowing logins as 'root' to use binaries that overwrite files
without prompting is the "smoking gun" that eventually seems to
shoot newbies in the foot given enough time they get
bored/curious and go for it. :-) 

>
>        ,                          ,
>      o/      Charles.Angelich      \o       ,
>       __o/
>     / >          USA, MI           < \   __\__
 

--- * ATP/16bit 2.31 * 
... DOS the Ghost in the Machine! http://www.undercoverdesign.com/dosghost/