Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU |
On Sat, Jul 26, 2008 at 05:13:05AM -0700, Anil Saini wrote: > how to restrict media file to be write or create on linux file system The prototypical example of how to do this on Unix systems is syslogd: provide a daemon or SUID program that has write access to the file the user wants to write, taking the file as input. This approach has the drawback that the program used to police access becomes a potential security hole if it is not written well. Specifically, if the program contains a buffer overflow, or other exploitable code, then a user can make use of this program to gain access to any system resource which that program would normally have access to. A possible alternative (with alternative drawbacks) is to use extended ACLs. I say "possible" because I've never actually used them, and I tend to think it won't work for reasons I describe below. You also will need to ensure that support for it is compiled into your kernel, if I'm not mistaken, which I believe is generally not the case by default... For more info, see the man pages for setfacl and getfacl. Using extended ACLs has the often-overlooked drawback that it actually greatly complicates access management; widespread use of extended ACLs, if not done with great care, could turn managing permissions into a small nightmare. I've seen it happen (though admittedly in a different context)... The key to restricting a file to be write-only, by (likely) any method, is that you must find a way to allow the user to create the file without owning it. Otherwise, the user can generally just undo whatever security measure you used. For this reason, I think the extended ACL method won't actually work, at least not alone. This almost certainly requires some kind of wrapper program. syslogd accomplishes this by running as root (which your program need not, and SHOULD not, do) and providing a socket through which programs can write data which syslogd will log to the appropriate file. In fact, if you were a little crazy, you could actually use syslogd to provide this kind of functionality. The trouble being that it would simply continually append any new data logged to whatever file it was configured to log into. It's very unlikely that this is what you want. But, you can set default ACLs on a directory, which is what you'd need to do if you wanted to try to solve this using extended ACLs, assuming that the user can't override them for files he owns. My assumption is the opposite, but I have no systems conveniently available where this support is enabled, so I can't test it. I'd be curious about the results, if someone did... > or also how to limit file size to be created in a particular folder > say /tmp folder One way is to use logrotate. This probably doesn't do what you really want, but depending on the use case, it might be adequate. Usually logrotate is configured to watch specific files, which may not work for your use case. Then, you initiate logrotate as a cron job periodically, which probably also won't work, unless it's OK for the configured files to grow beyond the limit you set until the next time cron runs logrotate... Another possibility is to use ulimit, though this also may not be what you really want, since it limits the size of *all* files created by child processes of the process where the ulimit was changed. However, it may be useful in conjunction with a wrapper script (which sets the ulimit), depending on what you are trying to do. Also, Jerry's suggestion is an excellent one. If /tmp is not already its own filesystem, you could make it a separate file system. Then enable quotas on it. This is probably the best way to get what you want, though it probably has the highest learning curve and set-up time. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. _______________________________________________ Discuss mailing list [hidden email] http://lists.blu.org/mailman/listinfo/discuss
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |