Testing apps on dual booting machine.

[M.Rudra]

Hello List ,
Currently I use FC-1 and also have a dual boot machine with win-XP.
My question : 
I have not programmed  with Linux, but would like to. So if i create a
seperate *user* and download any linux application under development
to fiddle with, will it crash my dual boot or linux box ?
I had read a few articles/blogs about problems with
testing/programming on a dual booting FC and XP machine. I dont want
that problem :-) as i wouldnt know how to fix it.
This is my home PC - I use it for regular stuff (music, email,
browsing, office apps, other stuff...) and yet I want it to be
stable....
Any suggestions/info/ideas welcome.. 
thanks..MR

[James Wilkinson]

M.Rudra wrote:
> Currently I use FC-1 and also have a dual boot machine with win-XP.
> My question : 
> I have not programmed  with Linux, but would like to. So if i create a
> seperate *user* and download any linux application under development
> to fiddle with, will it crash my dual boot or linux box ?
> I had read a few articles/blogs about problems with
> testing/programming on a dual booting FC and XP machine. I dont want
> that problem :-) as i wouldnt know how to fix it.
> This is my home PC - I use it for regular stuff (music, email,
> browsing, office apps, other stuff...) and yet I want it to be
> stable....

Very short answer: No.

Short answer: It depends, but probably not.

Long answer: If you're doing kernel mode programming, X sever
programming, or anything that needs privileged access to hardware, then
all bets are off. But it doesn't sound as though you're ready for that,
yet, and you'd know if you were doing it.

If you run your programs as root, then there is the chance for those
programs to trash your system.

Otherwise, the very worst that you can do is trash your user files. And
the chance of that, normally, is very remote.

Unix (except in the early versions), and Linux (and Windows XP, come to
that) have memory management. They use the MMU and "privileged modes" in
the processor to ensure that normal programs can't fiddle with memory
that they're not supposed to access. This means that they can't crash
the entire OS, or get around the filesystem's permission flags.

It would be very impressive to produce a program bug that could trash
user files unrelated to the program, unless you were playing around with
"find" and "rm" type functionality. But as you imply, if you do
development and testing as a separate user, and if you've got the
permission flags set appropriately (which they should be for /home, but
check any shared directories or vfat mounts), then even such a bug will
only affect the development user.

Very few developers bother.

You should have good backups of anything you care about: this is simply
normal good practice whether you program or not.

James.

[M.Rudra]

On Mon, 24 Jan 2005 18:04:31 +0000, James Wilkinson
 wrote:
> M.Rudra wrote:
> > Currently I use FC-1 and also have a dual boot machine with win-XP.
> > My question :
> > I have not programmed  with Linux, but would like to. So if i create a
> > seperate *user* and download any linux application under development
> > to fiddle with, will it crash my dual boot or linux box ?
> > I had read a few articles/blogs about problems with
> > testing/programming on a dual booting FC and XP machine. I dont want
> > that problem :-) as i wouldnt know how to fix it.
> > This is my home PC - I use it for regular stuff (music, email,
> > browsing, office apps, other stuff...) and yet I want it to be
> > stable....
>
> Very short answer: No.
>
> Short answer: It depends, but probably not.
>
> Long answer: If you're doing kernel mode programming, X sever
> programming, or anything that needs privileged access to hardware, then
> all bets are off. But it doesn't sound as though you're ready for that,
> yet, and you'd know if you were doing it.
>
> If you run your programs as root, then there is the chance for those
> programs to trash your system.
>
> Otherwise, the very worst that you can do is trash your user files. And
> the chance of that, normally, is very remote.
>
> Unix (except in the early versions), and Linux (and Windows XP, come to
> that) have memory management. They use the MMU and "privileged modes" in
> the processor to ensure that normal programs can't fiddle with memory
> that they're not supposed to access. This means that they can't crash
> the entire OS, or get around the filesystem's permission flags.
>
> It would be very impressive to produce a program bug that could trash
> user files unrelated to the program, unless you were playing around with
> "find" and "rm" type functionality. But as you imply, if you do
> development and testing as a separate user, and if you've got the
> permission flags set appropriately (which they should be for /home, but
> check any shared directories or vfat mounts), then even such a bug will
> only affect the development user.

thanks James ...both  answers are reassuring for a non-geek like me.
and i am definitely not geared for kernel programing or anything that
demanding.  I switched to linux first out of curiosity.
The system has a partition and allows access to windows via linux but
as root (is that safe ?...not sure about user's. ?- how do i find out
?)
If i create a *User* for testing packages what options should i turn
off and what permission flags need to be set. I am not conversant with
command line interfaces so any links to finding that info is also
useful. Do they differ for each package/program ?

[James Wilkinson]

M.Rudra wrote:
> The system has a partition and allows access to windows via linux but
> as root (is that safe ?...not sure about user's. ?- how do i find out
> ?)

So root can write, but normal users can't? Or can normal users not even
read it?

It's "safe" as in support for vfat is very good, so you're not going to
lose data to a filesystem bug. [1] It's good practice not to use root
more often than necessary, so you may want to give normal users *more*
access: investigate the dmask and fmask options in man mount and man
fstab.

(Unlike "real" Unix-like filesystems, vfat has no support for user ids
and very little support for permissions. Under Linux, you'll find that
all files on a vfat partition have the same permissions. This is good
for your purposes: if one file is safe, then they all are).

You might want to set up a group for accessing the vfat partition: put
your normal user account in it, so it can read and write, and leave your
development user account out, so it can't write to the partition.

I don't know if you know how to read ls -l output: take a look at
http://www.tldp.org/HOWTO/Unix-and-Internet-Fundamentals-HOWTO/disk-layout.h...
> If i create a *User* for testing packages what options should i turn
> off and what permission flags need to be set. I am not conversant with
> command line interfaces so any links to finding that info is also
> useful. Do they differ for each package/program ?

Just make sure that it is a different user with a different user ID:
that's automatic, and the rest of the security is automatic, too. Unix
and Fedora security is designed to cope with one central (large)
computer for a university's worth of mischievous undergrads, and prevent
any of them messing around with any other account.

To be paranoid, you might want to run
find ~ -type d -o -type f -perm -2 -ls
to check that there are no world-writable files in your home directory.

James.

[1] Well: it's *extremely* unlikely.

[M.Rudra]

Thanks james, excuse the delay as i was out :-)

James Wilkinson  wrote:
> So root can write, but normal users can't? Or can normal users not even
> read it?

root can read but users cant access files in winXP c:/d:/e: partition
drives  (maybe permissions are not set) and what is the procedure to
do that  ?
> It's "safe" as in support for vfat is very good, so you're not going to
> lose data to a filesystem bug. [1] It's good practice not to use root
> more often than necessary, so you may want to give normal users *more*
> access: investigate the dmask and fmask options in man mount and man
> fstab.

i did try that and this is the result :

[rudra@localhost rudra]$ dmask
bash: dmask: command not found
[rudra@localhost rudra]$ fmask
bash: fmask: command not found
[rudra@localhost rudra]$ fstab
bash: fstab: command not found
> (Unlike "real" Unix-like filesystems, vfat has no support for user ids
> and very little support for permissions. Under Linux, you'll find that
> all files on a vfat partition have the same permissions. This is good
> for your purposes: if one file is safe, then they all are).
> You might want to set up a group for accessing the vfat partition: put
> your normal user account in it, so it can read and write, and leave your
> development user account out, so it can't write to the partition.
> I don't know if you know how to read ls -l output: take a look at
> http://www.tldp.org/HOWTO/Unix-and-Internet-Fundamentals-HOWTO/disk-layout.h...

thanks, i will look into it and reply when i return on 15-feb.
> Just make sure that it is a different user with a different user ID:
> that's automatic, and the rest of the security is automatic, too. Unix

i did notice that and used some GUI apps to set permissions, but had a
bad experience so gave it up. CLI dependence is tough for a
non-programmer partly due to the few resources available.
> To be paranoid, you might want to run
> find ~ -type d -o -type f -perm -2 -ls
> to check that there are no world-writable files in your home directory.

it did not produce any error 
[rudra@localhost rudra]$ find ~ -type d -o -type f -perm -2 -ls
[rudra@localhost rudra]$

btw, where can i find a list of commands like the above with
explanations. Programming/Unix Books are more helpful for programmers.
  As a non-programmer (with time-constraints) i would still like
resources which have some basic commands for simple tasks and give
pointers to construct such commands on my own.
The *man* files list various options but pls understand that it does
not say what will go wrong if used incorrectly and in what
combination.... That is very risky as i will have to spend *more* time
undoing it.

Thanks again,

[Robert Storey]

On Wed, 2 Feb 2005 07:01:11 -0500
"M.Rudra"  wrote:
> Thanks james, excuse the delay as i was out :-)
>
> James Wilkinson  wrote:
> > So root can write, but normal users can't? Or can normal users not
> > even read it?
>
> root can read but users cant access files in winXP c:/d:/e: partition
> drives  (maybe permissions are not set) and what is the procedure to
> do that  ?
> > It's "safe" as in support for vfat is very good, so you're not going
> > to lose data to a filesystem bug. [1] It's good practice not to use
> > root more often than necessary, so you may want to give normal users
> > *more* access: investigate the dmask and fmask options in man mount
> > and man fstab.
>
> i did try that and this is the result :
>
> [rudra@localhost rudra]$ dmask
> bash: dmask: command not found
> [rudra@localhost rudra]$ fmask
> bash: fmask: command not found
> [rudra@localhost rudra]$ fstab
> bash: fstab: command not found
> > (Unlike "real" Unix-like filesystems, vfat has no support for user
> > ids and very little support for permissions. Under Linux, you'll
> > find that all files on a vfat partition have the same permissions.
> > This is good for your purposes: if one file is safe, then they all
> > are). You might want to set up a group for accessing the vfat
> > partition: put your normal user account in it, so it can read and
> > write, and leave your development user account out, so it can't
> > write to the partition. I don't know if you know how to read ls -l
> > output: take a look at
> > http://www.tldp.org/HOWTO/Unix-and-Internet-Fundamentals-HOWTO/disk-
> > layout.html#permissions

I had something like this set up a few years ago (when I was still using
Windows/DOS in a dual-boot system with Linux). I still have the notes on
it - I set it up as follows...

Add a line in /etc/fstab like:

/dev/hda1  /dos   vfat   rw,noexec,uid=1015,gid=102,umask=007, 0 0

The uid and gid are for a user dos and group dos which I created. The
user dos has a ! in /etc/passwd where the password entry would go so
it cannot log in.  I add any users which need access to that
partition to group dos. Any files in that partition are only readable
and writeable by user dos and members of group dos.

That should do it.

regards,
Robert

[Jeff Vian]

On Wed, 2005-02-02 at 07:01 -0500, M.Rudra wrote:
> Thanks james, excuse the delay as i was out :-)
>
> James Wilkinson  wrote:
> > So root can write, but normal users can't? Or can normal users not even
> > read it?
>
> root can read but users cant access files in winXP c:/d:/e: partition
> drives  (maybe permissions are not set) and what is the procedure to
> do that  ?
> > It's "safe" as in support for vfat is very good, so you're not going to
> > lose data to a filesystem bug. [1] It's good practice not to use root
> > more often than necessary, so you may want to give normal users *more*
> > access: investigate the dmask and fmask options in man mount and man
> > fstab.
>
> i did try that and this is the result :
>
> [rudra@localhost rudra]$ dmask
> bash: dmask: command not found
> [rudra@localhost rudra]$ fmask
> bash: fmask: command not found
> [rudra@localhost rudra]$ fstab
> bash: fstab: command not found

James did not say use those commands.  He said to check the options.
Use "man mount" and "man fstab" to see what he meant.
> > (Unlike "real" Unix-like filesystems, vfat has no support for user ids
> > and very little support for permissions. Under Linux, you'll find that
> > all files on a vfat partition have the same permissions. This is good
> > for your purposes: if one file is safe, then they all are).
> > You might want to set up a group for accessing the vfat partition: put
> > your normal user account in it, so it can read and write, and leave your
> > development user account out, so it can't write to the partition.
> > I don't know if you know how to read ls -l output: take a look at
> > http://www.tldp.org/HOWTO/Unix-and-Internet-Fundamentals-HOWTO/disk-layout.h...
>
> thanks, i will look into it and reply when i return on 15-feb.
> > Just make sure that it is a different user with a different user ID:
> > that's automatic, and the rest of the security is automatic, too. Unix
>
> i did notice that and used some GUI apps to set permissions, but had a
> bad experience so gave it up. CLI dependence is tough for a
> non-programmer partly due to the few resources available.
> > To be paranoid, you might want to run
> > find ~ -type d -o -type f -perm -2 -ls
> > to check that there are no world-writable files in your home directory.
>
> it did not produce any error 
> [rudra@localhost rudra]$ find ~ -type d -o -type f -perm -2 -ls
> [rudra@localhost rudra]$
>
> btw, where can i find a list of commands like the above with
> explanations. Programming/Unix Books are more helpful for programmers.
>   As a non-programmer (with time-constraints) i would still like
> resources which have some basic commands for simple tasks and give
> pointers to construct such commands on my own.
> The *man* files list various options but pls understand that it does
> not say what will go wrong if used incorrectly and in what
> combination.... That is very risky as i will have to spend *more* time
> undoing it.
> Thanks again,
>
> MR