Re: [RFC PATCH] file as directory
Miklos Szeredi wrote: Why do we want this? That depends on who you ask. My answer is this: 'foo.tar.gz/foo/bar' or 'foo.tar.gz/contents/foo/bar' or something similar. Others might suggest accessing streams, resource forks or extended attributes through such an interface. However this patch only deals with the non-directory case, so directories would be excluded from that interface. here's a possibly stupid question. What about symlinks to dirs? namely the shells tend to treat them differently if postfixed with a slash or not. - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 10/14] In-kernel file copy between union mounted filesystems
Bharata B Rao wrote: Not really. This is called during copyup of a file residing in a lower layer. And that is done only for regular files. That is broken. You should be able to change the permissions on a device node on a layer that is RO. so it would copy it up (1. mknod, 2. copy attributes) and then the appropriate attribute notification change would be called. - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 7/8] allow unprivileged mounts
Andrew Morton wrote: On Fri, 20 Apr 2007 12:25:39 +0200 Miklos Szeredi [EMAIL PROTECTED] wrote: Define a new fs flag FS_SAFE, which denotes, that unprivileged mounting of this filesystem may not constitute a security problem. Since most filesystems haven't been designed with unprivileged mounting in mind, a thorough audit is needed before setting this flag. Practically speaking, is there any realistic likelihood that any filesystem apart from FUSE will ever use this? Would it be interesting to support mounting of external file systems (be it USB, NFS or whatever) in a way that automatically forces it to ignore suid and devices (which are already mount time options)? The question I guess is, how much do you gain over a setuid program (hack?) that can handle this? - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AppArmor FAQ
James Morris wrote: On Tue, 17 Apr 2007, Alan Cox wrote: I'm not sure if AppArmor can be made good security for the general case, but it is a model that works in the limited http environment (eg .htaccess) and is something people can play with and hack on and may be possible to configure to be very secure. Perhaps -- until your httpd is compromised via a buffer overflow or simply misbehaves due to a software or configuration flaw, then the assumptions being made about its use of pathnames and their security properties are out the window. Without security labeling of the objects being accessed, you can't protect against software flaws, which has been a pretty fundamental and widely understood requirement in general computing for at least a decade. And that's why apparmor should be implemented as a stackable file system with a container mechanism, and I implemented such a thing back in 2003, albiet mostly just proof of concept and a horribly written paper (it was my first), so never got published beyond a tech report. http://www.ncl.cs.columbia.edu/publications/cucs-005-04.pdf Basically, on disk labeling is not necessarily an easy mechanism for app armor type things as it's not easy to use and different applications have different requirements so end up w/ multiple labels attached that are difficult to understand. That's why app armor's path based rules are nice, each app has its own set of rules, and one can easily eyeball what rules apply to each app, as well as easily change it. However, since apparmor has no conception of the actual file system, so it's broken by design. If on the other hand it was implemented as a stackable file system, each fs object would be labeled. The same underlying FS could be used by multiple distinct applications w/ distinct security issues, and one could even combine it with something like unionfs to give each domain a separate writable area, avoiding the output file issue, where output filess could be used to attack the system. - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AppArmor FAQ
On Wed, 18 Apr 2007, Crispin Cowan wrote: Please explain why labels are necessary for effective confinement. Many systems besides AppArmor have used non-label schemes for effective confinement: TRON, Janus, LIDS, Systrace, BSD Jail, EROS, PSOS, KeyOS, AS400, to name just a few. This claim seems bogus. Labels may be your method of choice for confinement, but they are far from the only way. One problem with AppArmor and Janus and Systrace and everything else that relies on pathname resolution is the point where they do the pathname resolution. If you read the janus, systrace, subdomain (apparmor's predecssor?) papers, you'll see how they have to jump through hoops to handle things like symlinks, when there's no fundamental reason why they have to. If one simply worked at the FS level, all one cares about is lookup() and permission. You have a set of rules that lookup() is able to use to dynamically tag dentries and permission() then checks that tag. One doesn't jump through hoops anymore. So, while I sound like a broken record, something like a stackable file system works wonders here (I know, I implemented one). Now, stackable file systems aren't perfect here (mount point crossing, additional mounted file systems on top of the stackable file system) can cause problems, overall it seems like a cleaner solution. Another option would be if the LSM could be extended to allow a simple method of storing private data along with every dentry/inode (the main reason one needs a stackable file system). In this way, if the lookup() oepration was extended to be able to take a function that filled in that data and permission() was able to be extended to take a function that could use that data, one wouldn't even need a stackable file system, but one would still be operating at the simplest layer (which is the file system). - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [AppArmor 00/41] AppArmor security module overview
[EMAIL PROTECTED] wrote: This post contains patches to include the AppArmor application security framework, with request for inclusion. question in general, these seems like a fairly invasive series of patches. back when I first started graduate school, I prototyped a relatively simple stackable file system on 2.4 that seems to be able to do a lot of what app armor does (or at least seems to be easily extensible to o everything app armor does) from an fs perspective, without having to modify the kernel at all, why not use that approach? What I did back then was I took Erez Zadok's fist, created his base0fs, which basically does nothing, just passes everything directly down. I viewed it as a null stackable fs. I then modified it to a) contain a set of rules (be able to add, delete, modify them) b) fs's private lookup() determines if a dentry matches a rule and tags it (stored in dentry private data, but inode can be used as well) c) fs's private permission() checks the rule data stored in private data to determine if the generic_permission should be even called. what I didn't do is mmap or hard link, but those are additional checks one can do in those specific f_ops. Basically, why force the VFS to change, when one can create an apparmorfs that stacks on top of whatever fs you want to use app armor rules with, create a namespace containing that new stacked fs only (to contain processes within the stacked fs). This approach doesn't suffer from the normal stackable file system issue since there should be no complex what I'll call cache coherency issues due to the stackable directory entry namespace being the same exact as the underlying namespace and it passing down page cache operations directly to the lower fs. So one could stack on top of a file system one is using for both apparmor protected and unprotected processes. I could imagine there might be an issue w/ how one deals with special file systems (ala proc and others). But the way we approached this in general, is that this is an aspect of containers. namely, each protected area is a container itself, and hence has its own private virtualized proc my code was mostly prototype level (As well as only for 2.4), but it would seem to very easily to duplicate in a production level quailty for 2.6. anyways, just a thought - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL -mm] Unionfs branch management code
Andrew Morton wrote: On Mon, 9 Apr 2007 10:53:51 -0400 Josef 'Jeff' Sipek [EMAIL PROTECTED] wrote: The following patches introduce new branch-management code into Unionfs as well as fix a number of stability issues and resource leaks. I have a mental note that unionfs is in the stuck state, due to general agreement that we should implement this functionality at the VFS level, one reason for which is unionfs's upper-vs-lower coherency problems. How can a union file system with a decent set of useful semantics be fully implemented at the VFS layer in a clean manner? For instance, a major use of unionfs is live CDs, namely unionfs w/ a read-only and read-write layer. Unionfs enables files to be copied up from the read-only layer to the read-write layer. Does one really want to implement copyup in the VFS? just my 2 agarot. - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mount option to ignore permissions
Ihar `Philips` Filipau wrote: Hi! [ Please CC: me, I'm not subscribed. Yet. ] The problem have beaten me before. And now I have it again. Imaging external hard drive with proper file system (proper == supports posix permissions) where files were created by user A and then it (ext. hard drive) was brought to another location/computer and user B tried to read them. Failure. Why? Because Linux preserved permissions on hard drive - though they are already irrelevant on system fs is currently mounted on. And that renders literally all files accessible only by root. What is needed is special mount option to tell file system (*): (1) to ignore permissions when file/directory is read; (2) when file/directory is created it receives automatically world writable permissions 0666 (I cannot imaging how to simulate user friendly file attribute read-only, though it seems not relevant to external storage anyway). it's not just hard drives, I've found badly mastered video DVDs that have written the files to only be readable by the owner (UDF supports a normal owner,group,world semantic). Of course they test it in windows which ignores those bits of the fs and everything worked fine, but if one tries to use it in linux, it can only be played as root. As it's a DVD, one has no ability to change the permissions, and one might not even be able to easily extract and copy it to a new disk if its larger than what a DVD+-R can hold (ignoring less common DL disks for now). My assumption is, if someone is mounting media, it should be assumed he owns the media, and he should be able to disable permission checking for that mount point if he desires. right now there is no way to do that. - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/24] Unionfs: Documentation
Erez Zadok wrote: I didn't know about those patches, but yes, they do sound useful. I'm curious who needed such functionality before and why. If someone can point me to those patches, we can look into using them for Unionfs. Thanks. I asked for it years ago, You can probably guess why :) see http://marc.theaimsgroup.com/?l=linux-fsdevelm=105419650921086w=2 just had too many other things to do then follow the roadmap Al gave. - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/24] Unionfs: Documentation
On Tue, 2007-01-09 at 11:30 -0500, Trond Myklebust wrote: On Tue, 2007-01-09 at 13:15 +0100, Jan Kara wrote: On Mon, Jan 08, 2007 at 11:18:52AM -0800, Andrew Morton wrote: On Sun, 7 Jan 2007 23:12:53 -0500 Josef 'Jeff' Sipek [EMAIL PROTECTED] wrote: snip Any such change can cause Unionfs to oops, or stay silent and even RESULT IN DATA LOSS. With a rather rough user interface ;) That statement is meant to scare people away from modifying the lower fs :) I tortured unionfs quite a bit, and it can oops but it takes some effort. But isn't it then potential DOS? If you happen to union two filesystems and an untrusted user has write access to both original filesystem and the union, then you say he'd be able to produce oops? That does not sound very secure to me... And if any secure use of unionfs requires limitting access to the original trees, then I think it's a good reason to implement it in unionfs itself. Just my 2 cents. You mean somebody like, say, a perfectly innocent process working on the NFS server or some other client that is oblivious to the existence of unionfs stacks on your particular machine? To me, this has always sounded like a showstopper for using unionfs with a remote filesystem. Again, what about fibre channel support? Imagine I have multiple blades connected to a SAN. For whatever reason I format the san w/ ext3 (I've actually done this when we didn't need sharing, just needed a huge disk, for instance for doing benchmarks where I needed a large data set that was bigger than the 40GB disk that the blades came with). I better not touch that disk from any of the other blades. All you are saying is unionfs should always make sure its data is sane, never make assumptions about it being correct. Put it this way, imagine I have an ext3 fs on a SAN, I can only use it frm one machine. Lets say I want to be smart and mount the FS read-only from another machine, should I have any expectation that it will work? Nope. Now, under what conditions can one expect unionfs to work? Basically, where the underlying FS isn't being modified (though possible others). Is that a reasonable condition. I believe so. If you disobey the condition, the machine shouldn't oops, but it should detect it and tell you and shut down usage of the FS. - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/24] Unionfs: Documentation
On Tue, 2007-01-09 at 12:03 -0500, Trond Myklebust wrote: I'm saying that at the very least it should not Oops in these situations. As to whether or not they are something you want to handle more gracefully, that is up to you, but Oopses are definitely a showstopper. I don't think anyone involved disagrees. Any oops is a bug that has to be fixed. - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/24] Unionfs: Documentation
On Mon, 8 Jan 2007, Andrew Morton wrote: On Sun, 7 Jan 2007 23:12:53 -0500 Josef 'Jeff' Sipek [EMAIL PROTECTED] wrote: +Modifying a Unionfs branch directly, while the union is mounted, is +currently unsupported. Does this mean that if I have /a/b/ and /c/d/ unionised under /mnt/union, I am not allowed to alter anything under /a/b/ and /c/d/? That I may only alter stuff under /mnt/union? If so, that sounds like a significant limitation. haven't we been through this? It's the same thing as modifying a block device while a file system is using it. Now, when unionfs gets confused, it shouldn't oops, but would one expect ext3 to allow one to modify its backing store while its using it? - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/24] Unionfs: Documentation
On Mon, 2007-01-08 at 21:24 +0100, Jan Engelhardt wrote: On Jan 8 2007 14:43, Shaya Potter wrote: On Mon, 8 Jan 2007, Andrew Morton wrote: On Sun, 7 Jan 2007 23:12:53 -0500 Josef 'Jeff' Sipek [EMAIL PROTECTED] wrote: +Modifying a Unionfs branch directly, while the union is +mounted, is currently unsupported. Does this mean that if I have /a/b/ and /c/d/ unionised under /mnt/union, I am not allowed to alter anything under /a/b/ and /c/d/? That I may only alter stuff under /mnt/union? If so, that sounds like a significant limitation. haven't we been through this? It's the same thing as modifying a block device while a file system is using it. Now, when unionfs gets confused, it shouldn't oops, but would one expect ext3 to allow one to modify its backing store while its using it? (Blunt counter-example: Modifying the underlying filesystem of an NFS import does not break. But I agree with Shaya.) Well it was suggested to make /a/b and /c/d read-only while the union is mounted, using a ro bind mount, what about it? (To catch unwanted tampering with the lowlevels) not quite true. Run a program on an NFS root based system, modify the files it has mmaped (on the NFS server). Do you expect the program to behave correctly? Locally, you wouldn't be able to modify it (you would have to move it away and put a new copy in its place), I could be wrong, but I don't think that limitation exists if doing it with NFS. - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/24] Unionfs: Documentation
On Mon, 2007-01-08 at 13:19 -0800, Andrew Morton wrote: On Mon, 8 Jan 2007 14:43:39 -0500 (EST) Shaya Potter [EMAIL PROTECTED] wrote: It's the same thing as modifying a block device while a file system is using it. Now, when unionfs gets confused, it shouldn't oops, but would one expect ext3 to allow one to modify its backing store while its using it? There's no such problem with bind mounts. It's surprising to see such a restriction with union mounts. the difference is bind mounts are a vfs construct, while unionfs is a file system. - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/24] Unionfs: Documentation
Is there vendor interest in unionfs? MANY live cds seem to use it. - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Is a NULL check missing in nfs_lookup?
yes, you're writing a stackable file system (the cs.sunysb gives that away) and have run a lookup_one_len() on a nfs mounted file system and that means nd is null. Erez's group is trying to fix that situation so the intents can be passed correctly. On Thu, 2007-01-04 at 19:00 -0500, Chaitanya Patti wrote: Hello everyone, In the function nfs_lookup in nfs/dir.c , the following line (line # 926): error = nfs_reval_fsid(nd-mnt, dir, fhandle, fattr); uses `nd' without having checked if it is NULL. Is this correct? This is in kernel version 2.6.19.1 Can someone check this ? Thanks, Chaitanya. - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
