Re: Mounting ramfs with given permissions
On Tue, Nov 21, 2000 at 12:29:26PM -0800, H. Peter Anvin wrote: > By author:Pavel Roskin <[EMAIL PROTECTED]> > In newsgroup: linux.dev.fs.devel > > > > Hello, David! > > > > Thank you very much for the informative reply! > > > > > Currently there is now way to specify the permissions of the ramfs > > > root directory at mount time: it's always root.root, 0755. Somebody > > > did post a patch which added this. However, I'm not sure it's worth > > > addiding this in the kernel, rather than just putting a chmod command > > > in the startup scripts. Alternatively that functionality could be put > > > into mount(8). > > > > I did more research on the topic and now I'm quite confident that this > > option should be in the kernel for consistency with devpts. > > I would disagree with that. The reason devpts (and msdos, and quite a > few more) has "mode" is that they create additional device entries on > the fly, and need modes for *those*. In fact, in the case of devpts, > this mode isn't even used for the root. > > In the case of ramfs, this is a single node, and a single chown/chroot > system call should take care of that. HOWEVER, this assumes that > there isn't a window of opportunity for an attacker. Exactly. > Therefore, it is my (firm!) opinion that the permissions should start > out as mode 0700 with the mounting uid and gid as the owner. An > alternative would be to have mode 0777 modified by the mounting umask. I thought about that, and considered changing the mode. However the mode is already 0755, which means the worst an attacker can do is to see the empty root directory briefly before it is chmod-ed. Unless I'm missing something, there is no problem. -- David Gibson, Technical Support Engineer, Linuxcare, Inc. +61 2 6262 8990 [EMAIL PROTECTED], http://www.linuxcare.com/ Linuxcare. Support for the revolution. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
Re: Mounting ramfs with given permissions
Followup to: <[EMAIL PROTECTED]> By author:Pavel Roskin <[EMAIL PROTECTED]> In newsgroup: linux.dev.fs.devel > > Hello, David! > > Thank you very much for the informative reply! > > > Currently there is now way to specify the permissions of the ramfs > > root directory at mount time: it's always root.root, 0755. Somebody > > did post a patch which added this. However, I'm not sure it's worth > > addiding this in the kernel, rather than just putting a chmod command > > in the startup scripts. Alternatively that functionality could be put > > into mount(8). > > I did more research on the topic and now I'm quite confident that this > option should be in the kernel for consistency with devpts. > I would disagree with that. The reason devpts (and msdos, and quite a few more) has "mode" is that they create additional device entries on the fly, and need modes for *those*. In fact, in the case of devpts, this mode isn't even used for the root. In the case of ramfs, this is a single node, and a single chown/chroot system call should take care of that. HOWEVER, this assumes that there isn't a window of opportunity for an attacker. Therefore, it is my (firm!) opinion that the permissions should start out as mode 0700 with the mounting uid and gid as the owner. An alternative would be to have mode 0777 modified by the mounting umask. -hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
Re: Mounting ramfs with given permissions
Hello, David! Thank you very much for the informative reply! > Currently there is now way to specify the permissions of the ramfs > root directory at mount time: it's always root.root, 0755. Somebody > did post a patch which added this. However, I'm not sure it's worth > addiding this in the kernel, rather than just putting a chmod command > in the startup scripts. Alternatively that functionality could be put > into mount(8). I did more research on the topic and now I'm quite confident that this option should be in the kernel for consistency with devpts. The right way would be probably to unify more filesystem options. For example, "bsdgroups" is meaningful on all read-write filesystems supporting ownership information, e.g. ext2, ufs, ramfs. "mode" makes sense for the systems that don't physically store the premissions, e.g. vfat, devpts, ramfs. However, the interpretation of "mode" is wildly different for those filesystems for the obvious reasons, but I don't consider that to be a problem. If that's correct, all non-kernel approaches should be considered as temporary hacks. > Incidentally, if you have any untrusted users on your system you > *don't* want to use ramfs for /tmp without applying the limits patch > (which unfortunately doesn't work right at the moment). Otherwise any > user can crash the system by exhausting physical memory. Thank you for the info. I do have untrusted users :-( Regards, Pavel Roskin - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
Re: Mounting ramfs with given permissions
On Mon, Nov 20, 2000 at 12:19:17PM -0500, Pavel Roskin wrote: > Hello! > > How do I mount ramfs so that the toplevel directory has permissions 1777 > (or whatever I want)? > > I can run "chmod 1777 /tmp" but it's not persistent over reboots if /tmp > is mounted as ramfs. > > I did try (unsuccessfully) > mount -o mode=1777 -t ramfs none /tmp Currently there is now way to specify the permissions of the ramfs root directory at mount time: it's always root.root, 0755. Somebody did post a patch which added this. However, I'm not sure it's worth addiding this in the kernel, rather than just putting a chmod command in the startup scripts. Alternatively that functionality could be put into mount(8). Incidentally, if you have any untrusted users on your system you *don't* want to use ramfs for /tmp without applying the limits patch (which unfortunately doesn't work right at the moment). Otherwise any user can crash the system by exhausting physical memory. -- David Gibson, Technical Support Engineer, Linuxcare, Inc. +61 2 6262 8990 [EMAIL PROTECTED], http://www.linuxcare.com/ Linuxcare. Support for the revolution. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
