Christoph Hellwig wrote:
On Fri, Apr 29, 2005 at 04:09:09PM -0500, Steve French wrote:
does and who revied that? Things like that don't have a business in the
kernel, and certainly not as ioctl.
Other filesystems such as smbfs had an ioctl that returned the uid of
the mounter which they used (in the smbfs case in smbumount). This was
required by the unmount helper to determine if the unmount would allow a
user to unmount a particular mount that they mounted. Unlike in the
case of mount, for unmount you can not use the owner uid of the mount
target to tell who mounted that mount. I had not received any better
suggestions as to how to address it. I had proposed various
alternatives - exporting in in /proc/mounts e.g.
exporting the uid using the show_options superblock methods sounds like
a much better option.
No. /proc/self/mounts is an ASCII format, so there's no problem with
differemt sizes.
I agree that it would work for most cases [today, in 2.6 Linux] - but I
really feel uncomfortable introducing a user space / kernel space
dependency on the size of a field where none is needed - I am especially
nervous because I can see from the Samba change logs that:
1) historically the size of this field changed
2) other operating systems also have either increased the size of uid
(as MacOS e.g.) or mapped it (as Windows does) - to accomodate the
needed concept of UUID (in large networks the current uid is too small)
Ideally I would have liked a general kernel call to be able to answer
the question "Does the current security context match that of the
mounter?" because with SELinux, and the need to increase the size of
uid or somehow work around it for distributed systems, it is hard for
user space code to take something opaque (the thing that showmounts
returns) and map it to what libc returns as the uid for current -
otherwise it would be impossible for user space code to guarantee that
it will match the kernel code, but this is so trivial, and has no
sideeffects so in the interim this seems safer.
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]