Date: Fri, 20 Jan 95 10:28:58 MST From: terry@cs.weber.edu (Terry Lambert) To: mcw@hpato.aus.hp.com (M.C Wong) Cc: freebsd-questions@freefall.cdrom.com Subject: Re: copy disabled filesystem Message-ID: <9501201728.AA12562@cs.weber.edu> In-Reply-To: <199501200623.AA242912999@hp.com> from "M.C Wong" at Jan 20, 95 05:22:25 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> OK, I am no great Novell fan nor user, but really like the idea of being > able to read a file but not allowing copy permission. On files, apart from trustee permissions, there are 32 bits of attribute information maintained by NetWare. This include read-only, copy inhibit, system, hidden, migrated, search permission, file vs. dir, etc. The copy inhibit works by denying the atomic copy operation. In UNIX and similar systems, there is no system call for copy -- that is, it's not an atomic operation. To make this work on your system, you would need to: 1) Add a "copy" system call at the vncalls layer. 2) Change your copy program to use it instead of reading then writing. 3) Steal a bit that you are guaranteed is initialized to 0 (so you don't get random behaviour when installing on an existing file system) and call it "copy inhibit". This must be part of the on-disk inode information for each file/directory. 4) Fail the copy when the bit is set. 5) Modify each fs that will support this to add either a vncall to all file systems for attribute information (and a null function to FS's not supporting it) OR add an ioctl entry point for the FS for setting the attribute given a vnode. This second approach is easiest, but ioctl's are, by default, refused with an ENOTTY except on the specfs (used to implement special devices in other file systems). 6) Probably steal a bit in the in core superblock for the FS that gets initted at mount time so given a vnode pointer, you can get the superblock pointer, and determine if the FS supports the capability or not OR you could make another ioctl call that is called on the vnode prior to each copy attempt, where an ENOTTY means that the FS doesn't support copy inhibit, 0 means OK and EPERM means denied. None of this will prevent either a user program or 'cat' doing it's thing and copying the file anyway. This kind of hackery is annoying at best, and a comment on the idea of inodes as fixed attribute blocks on the disk at worst. The whole idea of file systems needs to be reexamined. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9501201728.AA12562>