Not bad for 2 hours, I reckon.
> > > P.S.: i found another flaw. If someone does chmod a devfs block special
> > > sys_chmod/sys_fchmod in linux/fs/open.c updates the dentry but
> > > devfs internal cached mode for the inode never changes.
> > > If the block special contains a filesystem and you do mount/umount
> > > it, your changed permissions are gone afterwards.
> >
> > This is intentional. Permission changes are
> > filesystem-specific. Imagine you have a chroot() gaol and you want to
> > change some permissions there but you don't want to affect any other
> > mounted devfs'. The current behaviour supports this.
>
> That's not my problem.
>
> Different permissions in different mounted devfs _not_ affecting
> each other if changes are going on in one of them are o.k.
>
> > When you unmount a devfs, you lose all the permissions that were
> > cached. The current way to fix this is to manaully change the
> > permissions when you mount a devfs.
>
> If i do mount a filesystem using a block device special in one of
> the mounted devfs i _don't_ want the permissions be changed by that
> mount via the prefiously mentioned devfs_fill_file() scenario. The
> permissions should be the same as before the mount.
I don't understand what you're getting at. Your reference to
<devfs_fill_file> confuses me more: what does the internals of the
mounting process have to do with any permissions?
I must be missing the point.
Regards,
Richard....
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/