I agree with your evaluation, Pixel. 

Rationale: 
---------- 
Worrying about a largely theoretical Linux virus seems pretty pointless.
Let's think about the user base that we're targeting: 

* absolute beginners (the same ones likely to use autologin and msec 0):
will want to browse through their FAT32 filesystem to load and edit
their MS Word documents, then reboot into Windows for some other
application where they may also load the same document in MS Word again,
until they become accustomed to Linux and break ties with Windows. These
users are quite unlikely to quickly figure out how to change the mount
permissions, and not particularly likely to understand why they were
prevented from writing to those files in the first place... if it's
FAT32, in Windows they can delete pretty much anything they like. 

* power users: familiar with at least one desktop environment, able to
find drakconf and change the permissions to lock themselves out of FAT32
partitions if they so desire (or able to browse the HOWTOs and learn
enough to edit /etc/fstab to do the right thing) 

* LPIC-certified sysadmins: able to tweak /etc/fstab to their heart's
content 

Just to get my own biases out of the way, I'm LPIC-1 certified, but
(shh) probably closer to a power user than sysadmin. I would expect this
kind of setting to be determined by msec, and/or easily tweakable
through drakconf. 

Dan 

On Tue, 2003-01-21 at 20:05, Pixel wrote: 
> "[Bug 974]" <[EMAIL PROTECTED]> writes:
> 
> > The value of umask(=0) makes many system files on the FAT32 partition writable by 
>a  
> > non-root linux user. This is very undesirable and risky. In the extreme case, a  
> > well-designed linux virus can easily damage the windows system files !! 
> > The proper solution to this is to change the umask value to 022 so that only root 
>has 
> >  write access to the FAT32 system.
> 
> umask=0 is what people want AFAIK...
> 
> cooker people, WYT?
> 
> @resolution=invalid
> @product=Installation
> 

Attachment: signature.asc
Description: This is a digitally signed message part

Reply via email to