URL
https://opencores.org/ocsvn/or1k/or1k/trunk
Subversion Repositories or1k
[/] [or1k/] [trunk/] [linux/] [linux-2.4/] [fs/] [ChangeLog] - Rev 1275
Go to most recent revision | Compare with Previous | Blame | View Log
Mon Oct 24 23:27:42 1994 Theodore Y. Ts'o (tytso@rt-11)* fcntl.c (sys_fcntl): Liberalize security checks which Alan Coxput in.Thu Oct 20 23:44:22 1994 Theodore Y. Ts'o (tytso@rt-11)* fcntl.c (sys_fcntl): Add more of a security check to theF_SETOWN fcntl().[Tons of changes missed, indeed. This list is worth restarting sinceat least some fixes WILL break third-party filesystems. Sorry, butthere was no other way to fix rmdir/rename deadlock, for one.]Wed Dec 2 (Linus, fill the rest, please)* namei.c (do_rmdir) and rmdir method in filesystems:Locking of directory we remove was taken to VFS.See comments in do_rmdir(). Unfixed filesystemswill bloody likely deadlock in rmdir().Thu Dec 3 17:25:31 1998 Al Viro (viro@math.psu.edu)* namei.c (do_rmdir):Reject non-directories here.Two (probably) obsolete checks moved here too: we fail ifthe directory we remove is the same as parent (BUG: weserve mountpoints later) or if it lives on a differentdevice.* sysv/namei.c (sysv_rmdir): See sysv/CHANGESFri Dec 4 00:54:12 1998 AV* namei.c (check_sticky): New function check_sticky(dir, inode).If dir is sticky check whether we can unlink/rmdir/renamethe inode. Returns 1 if we can't. If dir isn't sticky -return 0 (i.e. no objections). Some filesystems requiresuser() here; some are fine with CAP_FOWNER. The laterseems more reasonable.* namei.c (do_rmdir):Moved the check for sticky bit here.* affs/{inode,namei}.c:All AFFS directories have sticky semantics (i.e. non-ownerhaving write permisssions on directory can unlink/rmdir/renameonly the files he owns), but AFFS didn't set S_ISVTX on them.Fixed. NB: maybe this behaviour should be controlled by mountoption. Obvious values being 'sticky' (current behaviour),'nonsticky' (normal behaviour) and maybe some play on 'D'permissions bit. FIXME.* qnx4/namei.c (qnx4_rmdir):Plugged inode leak.* ufs/namei.c (ufs_rmdir):Changed handling of busy directory to new scheme.Fri Dec 4 10:30:58 1998 AV* namei.c (VFS_rmdir): New function. It gets inode of the parent anddentry of the victim, does all checks and applies fs-specificrmdir() method. It should be called with semaphores downon both the victim and its parent and with bumped d_count onvictim (see comments in do_rmdir).* include/linux/fs.h: Added VFS_rmdir* kernel/ksyms.c: Added VFS_rmdir to export list (for NFSD).* nfsd/vfs.c: Fixed rmdir handling.Tue Dec 8 05:55:08 1998 AV* vfat/namei.c: Fixed the bug in vfat_rename() introduced in thefirst round of rmdir fixes.Wed Dec 9 03:06:10 1998 AV* namei.c (do_rename): part of fs-independent checks had been movedhere (sticky bit handling, type mismatches). Cases ofthe source or target being append-only or immutable also wenthere - if we check it for parent we could as well do it forchildren.* {affs,ext2,minix,sysv,ufs}/namei.c (do_*_rename):Removed tests that went to VFS, it simplified the code big way.Fixed a race in check for empty target - we should check forextra owners _before_ checking for emptiness, not after it.* {ext2,ufs}/namei.c (do_*_rename):VERY nasty bug shot: if somebody mkdired /tmp/cca01234, wentthere, rmdired '.', waited till somebody created a file withthe same name and said mv . /tmp/goodbye_sticky_bit... Well,goodbye sticky bit. Down, not across!* {minix,sysv}/namei.c (do_*_rename):Incorrect check for other owners (i_count instead of d_count).Fixed.* vfat: Looks like the changes above fixed a bug in VFAT - this beastused to allow renaming file over directory and vice versa.Wed Dec 9 08:00:27 1998 AV* namei.c (VFS_rename): New function. It gets the same arguments as->rename() method, does all checks and applies fs-specificrmdir() method. It should be called with semaphores downon both parents.* include/linux/fs.h: Added VFS_rename* kernel/ksyms.c: Added VFS_rename to export list (for NFSD).* nfsd/vfs.c: Changed rename handling (switched to VFS_rename).Wed Dec 9 18:16:27 1998 AV* namei.c (do_unlink): handling of sticky bit went here.* {affs,ext2,minix,qnx4,sysv,ufs}/namei.c (*_unlink):removed handling of sticky bit.* qnx4/namei.c (qnx4_unlink):Yet another inode leak. Fixed.Thu Dec 10 04:55:26 1998 AV* {ext2,minix,sysv,ufs}/namei.c (*_mknod):removed meaningless code handling attempts to mknod symlinksand directories. VFS protects us from _that_ and if this codewould ever be called we'ld get a filesystem corruption.Thu Dec 10 16:58:50 1998 AV* namei.c (do_rename): Fixed dentry leak that had been introduced bythe first round of rmdir fixes.Fri Dec 11 14:57:17 1998 AV* msdos/namei.c (msdos_rmdir): Fixed race in emptiness check.Sat Dec 12 19:59:57 1998 AV* msdos/namei.c (msdos_mkdir): Fixed the evil breakage introduced bythe changes of rmdir locking scheme. We shouldn't callmsdos_rmdir from there.Sun Dec 13 02:05:16 1998 AV* namei.c (do_unlink):Added new function: vfs_unlink, with the same arguments as->unlink() method.* kernel/ksyms.c: Made it exported.* include/linux/fs.h: Added prototype.* nfsd/vfs.c: Changed handling of unlink (switched to vfs_unlink)* {ext2,ufs}/namei.c (*_unlink): moved handling of imm./append-only toVFS.Wed Dec 16 06:10:04 1998 AV* namei.c (may_create, may_delete): New inline functions.They check whether creation/deletion is permitted.Checks from other places of namei.c went there.Looks like originally I misread permission-related stuffboth here and in nfsd. In particular, checks forimmutable are done in permission(). D'oh.* unlink on directory should return -EISDIR, not -EPERM as it used todo. Fixed.* rmdir of immutable/append-only directory shouldn't be allowed. Fixed.Remains unfixed:* rename's handling of races is, erm, not optimal. Looks like I knowwhat to do, but this thing needs some more cleanup - we cantake care of almost all races in VFS and be much more gracefulwrt locking. Moreover, it would give strong lookup atomicity.But it's a lot of changes to lookup and dcache code, so it willgo after the fs drivers' cleanup.* affs allows HARD links to directories. VFS is, to put it politely,not too ready to cope with _that_. And I'm not sure it shouldbe - looks like they are pretty much similar to symlinks.* truncate doesn't give a damn about IO errors and disk overflows (onbraindead filesystems). I've submitted a patch to Linus, butlooks like it wasn't applied.* msdos: shouldn't we treat SYS as IMMUTABLE? Makes sense, IMHO.
Go to most recent revision | Compare with Previous | Blame | View Log
