> Hi,
>
> I just came across a bit of a clanger. We had a file system mounted
> "nosuid", so of course users were getting "operation not permitted" trying
> to run an suid binary. No trouble I thought and did a
>
> mount -o remount,suid
>
> /proc/mounts showed this change as acknowledged.
>
> Alas trying to exec an suid program on the filesystem continued to fail in
> the same way until a full umount/mount of the filesystem in question was
> performed. Sigh.
This is because the remount code doesn't call invalidate_inodes(). Essentially,
you already have the inode already in the hash and it's marked as non-executable,
so when you remount the fs with suid, the inode is still there. You will have
no problem with a binary that's not been accessed while the fs was mounted nosuid.
2.1 is fine, I remember when the issue came up and Bill Hawes fixed it.
Yes, it's still a bug in 2.0.34pre, and here is a (trivial) fix for it.
Ion
--
It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.
---------------------------------------
--- /src/moisil/unpack/linux-2.0.34pre16/fs/super.c Thu May 21 20:57:09 1998
+++ linux-2.0.34/fs/super.c Fri May 22 22:16:53 1998
@@ -765,6 +765,7 @@
return retval;
}
sb->s_flags = (sb->s_flags & ~MS_RMT_MASK) | (flags & MS_RMT_MASK);
+ invalidate_inodes(sb->s_dev);
vfsmnt = lookup_vfsmnt(sb->s_dev);
if (vfsmnt)
vfsmnt->mnt_flags = sb->s_flags;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu