[RFE] Gnome/KDE --> Checkfs/Format......

Andrew Farris lordmorgul at gmail.com
Tue Mar 4 22:52:36 UTC 2008


Johann B. Gudmundsson wrote:
> Andrew Farris wrote:
>> Johann B. Gudmundsson wrote:
>>> Andrew Farris wrote:
>>>> � wrote:
>>>>> Is there really any need for the user to have root access to the 
>>>>> computer he's or
>>>>> to contact his system administrator ( in case he has one to begin 
>>>>> with )
>>>>> to format the floppy he wants to save his OO document on ????
>>>>> And when the user has not put his floppy disk properly in the 
>>>>> floppy drive
>>>>> is faced with "Unable to mount media <clicks> detail  -->
>>>>> and gets mount: /dev/fd0 is not a valid block device
>>>>> Instead of userfriendly msg like the cd/dvd rom outputs "There's 
>>>>> probably no media in drive"
>>>>> which by the way is true in this case...
>>>>
>>>> Mounting and creating filesystems is something that PolicyKit should 
>>>> allow to be configured, see 
>>>> System->Preferences->System->Authorizations.  This is really a 
>>>> matter of default polkit policy being written to make it happen 
>>>> (and/or to prevent it).  I think in some cases it would be valuable 
>>>> to prevent a user from formatting any disks (think internet kiosk or 
>>>> security sensitive data on a workstation).
>>>>
>>> We are talking about external HD,USB keys Floppy's..
>>> the same policy should apply to them as CD's ( burning cd or bootable 
>>> cd's )
>>> We are not letting users format internal HD without the necessary 
>>> privileges.
>>
>> I was talking about external devices.  Its your opinion they should be 
>> fully open to format, its my opinion they should be permitted to be 
>> formatted by default policy but be restrictable...
>>
> I'm not arguing against that it along with other things cant be 
> restricted..
> Regarding  "external devices" one must wonder how the security is  
> around the "external device" in the
> first place if the user gets its hands on it...  And since he got he's 
> hands on it in first place there's
> nothing to prevent him take it home or to his secret lair and do 
> whatever he wants to it...

If he's not allowed to mount it, format it, or move data to it even if he gets 
it connected to the machine, what he does with it (pick his nose?) is completely 
his business.  Yes, there is a major problem with security of any data once a 
user is physically touching the hardware, but that does not mean creating a good 
security policy around it is a bad idea anyway.

>>> Regarding internet kiosks workstations etc... then it's just common 
>>> sense
>>> to those who administer/manage to disable boot from CD's USB Floppy, 
>>> Password
>>> protect Grub and disable certain keyboard short cuts etc..
>>
>> The issue is not only booting, but the ability to lockdown the system 
>> and its behavior to only what is desired (be it browsing a library 
>> reference database or ordering coffee).
>>
> And this involves formating external storage device how???

I don't know, you brought up the booting not me.  A machine in that environment 
may not want users to have permission to format disks.. thats it.

>> I (the user) see it, policykit is an excellent route to take with 
>> setup for what you want.  The default desktop install could allow any 
>> user logged in to format external disks without root access if there 
>> is policy there to escalate their privileges for that task alone.
>>
> That was what you were trying to say policykit is an excellent way to 
> handle who can format and which devices are allowed to be formatted..

Yep thats all I was saying.  The user should be allowed to do it!  But it should 
be possible to choose not to let the user do it.  The root access permission 
requirement for doing those things has always been in place for that kinda of 
control AFAIK, and newer development like policykit may be changing this.

-- 
Andrew Farris <lordmorgul at gmail.com> www.lordmorgul.net
  gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3
No one now has, and no one will ever again get, the big picture. - Daniel Geer
----                                                                       ----




More information about the fedora-devel-list mailing list