Jamie Lokier <[EMAIL PROTECTED]> wrote: > Miklos Szeredi wrote: >>���4)�Access�should�not�be�further�restricted�for�the�owner�of�the >>������mount,�even�if�permission�bits,�uid�or�gid�would�suggest >>������otherwise >� >�Why?��Surely�you�want�to�prevent�writing�to�files�which�don't�have�the >�writable�bit�set?��A�filesystem�may�also�create�append-only�files�- >�and�all�users�including�the�mount�owner�should�be�bound�by�that.
That�will�depend�on�the�situation.�If�the�user�is�mounting�a�tgz�owned by�himself,�FUSE�should�default�to�being�a�convenient�hex-editor. >>���5)�As�much�of�the�available�information�should�be�exported�via�the >>������filesystem�as�possible >� >�This�is�the�root�of�the�conflict.��You�are�trying�to�overload�the >�permission�bits�and�uid/gid�to�mean�something�different�than�they >�normally�do. >� >�While�it's�convenient�to�see�some�"remote"�information�such�as�the >�uid/gid�in�a�tar�file,�are�you�sure�it's�a�good�idea�to�break�the�unix >�permissions�model�-�which�will�break�some�programs?��(For�example,�try >�editing�a�file�with�the�broken�semantics�in�an�editor�which�checks�the >�uid/gid�of�the�file�against�the�current�user). The�editor�will�try�to�keep�the�original�permissions,�and�saving�will�be less�effective. >>���1)�Only�allow�mount�over�a�directory�for�which�the�user�has�write >>������access�(and�is�not�sticky) >� >�Seems�good�-�but�why�not�sticky?��Mounting�a�user�filesystem�in >�/tmp/user-xxx/my-mount-point�seems�not�unreasonable�-�provided�the >�administrator�can�delete�the�directory�(which�is�possible�with >�detachable�mount�points). I�once�mounted�a�filesystem�in�~/tmp�after�forgetting�about�it�being�a symlink�to�/tmp/$me/tmp,�and�I�had�to�promise�never�to�do�that�again. Ng�zvqavtug,�gur�pyrnahc-grzc-fpevcg�xvpxrq�va. >>���5)�The�filesystem�daemon�is�free�to�fill�in�all�file�attributes�to >>������any�(sane)�value,�and�the�kernel�won't�modify�these. >� >�Dangerous,�because�an�administrative�program�might�actually�trust�the >�attributes�to�mean�what�they�normally�mean�in�the�unix�permissions�model. The�same�risk�applies�to�smbmounted�file�systems. Sane�daemons�will�do�no�check�besides�matching�the�owner�of�a�file�in�the user's�home�against�the�expected�UID�and�checking�the�permission�mask, since�you�can't�trust�users�not�to�mess�with�files�in�directories�they�own. The�"best"�they�can�do�should�be�shoothing�their�own�feet. (If�the�user�doesn't�own�the�directory,�FUSE�shouldn't�mount.) --� Top�100�things�you�don't�want�the�sysadmin�to�say: 80.�I�cleaned�up�the�root�partition�and�now�there's�LOTS�of�free�space. Fri�,�Spammer:[EMAIL PROTECTED]@whitedoc.info - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
