Re: good morning to all
* malathi selvaraj malathira...@gmail.com wrote: i am new one to freeBSD, kindly guide me Sure. In order to be eligible to use FreeBSD, you must buy a license for $ 100,-. I expect this money to be transferred to my bank account as soon as possible. The IBAN number is: NL30ABNA0385823426 You may also register at the secret special mailing list iwannalottaspam.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Simulating bad network conditions
Here is a link to a mailing list post about a patch to give dummynet support in pf. It is _fairly_ recent and so may still be a little buggy, but the poster seems quite confident that it works as intended. http://www.mail-archive.com/freebsd...@freebsd.org/msg03857.html Cheers, Tim. On 2009-02-18 11:42:00, Maxim Konovalov wrote: ipfw(8) prob + dummynet(8). Hi. Thanks for the quick response. Is there, by any chance, an equivalent for PF? I see there's 'ALTQ' but it looks to be poorly supported (unless I misunderstand). I have quite a complicated setup here with PF forwarding and jails and I'm not sure how well ipfw will play along. thanks, xw ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: What file on FreeBSD acts like autoexec.bat?
What file on FreeBSD acts like autoexec.bat? Also please leave the full path% ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] From my point of view, I would say that this file acts like an 'autoexec.bat' file, in a highly abstract manner: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ But I imaging the rc mechanism is more what you are looking for: http://www.freebsd.org/cgi/man.cgi?query=rcsektion=8 Cheers, Tim. -- The code that never executes at all is the fastest. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Idea for FreeBSD
On Wed, Aug 6, 2008 at 7:14 PM, [EMAIL PROTECTED] wrote: To who it may concern, I am A FreeBSD administrator as well as a Solaris Administrator. I use BSD at home but Solaris at work. I love both OS's but I would like to increase the administrative capability of FreeBSD. In Solaris 10 the Services Management Facility (SMF) was introduced. Basically what it does, is take all the rc.d scripts and puts them into a database to manage. Everything is converted to XML XML is good at document processing and for portable self-describing databases. Otherwise, I would think significantly less of any OS (or application) that used XML for configuration data. At least nothing that anyone would *every* be forced to edit manually. But of course the format of data in a database is largely irrelevant. You could implement the same thing with dbm files or a more forgiving text format. As for getting rid of rc.d scripts, yes they're decrepit and I would love to see them go but they're simple and third party software may depend on them being the norm. Just my 2c, Mike PS: I'm not a FreeBSD hacker or even an admin. ___ I believe the puppet project has a lot of potential, or if not the project then at least the ideas behind it, in regard to automating administrative tasks. I particularly like the way it allows the automation of the same tasks across different operating systems. http://reductivelabs.com/trac/puppet/ Cheers, Tim. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fwd: Q: case studies about scalable, enterprise-class firewall w/ IPFilter
Hello, I've posted the attached mail in the IP Filter mailing list; the only responses have been bad configured vacation replies :-( someone from freebsd-hackers has an idea? thanks in advance matthias - Forwarded message from Matthias Apitz [EMAIL PROTECTED] - From: Matthias Apitz [EMAIL PROTECTED] Date: Sun, 3 Aug 2008 08:24:15 +0200 To: IP Filter [EMAIL PROTECTED] Subject: Q: case studies about scalable, enterprise-class firewall w/ IPFilter Hello, We're currently protecting our network (and as well some FreeBSD laptops standalone) with IPFilter... I'm wondering if there are any case studies about scalable, enterprise-class firewall solutions, redundancy with state-full failover, and application-level inspection, and all that a like, based on IPFilter and FreeBSD; thanks in advance for any pointers matthias -- Hi there, I have never used ipfilter, but I do use pf, and it can do state-full failover, or firewall redundancy, with CARP (the Common Address Redundancy Protocol) and pfsync. If there is an equivalent syncing program, eg ipfiltersync then you could use that with CARP to allow an ipfilter firewall to fail-over with full state tables intact. Also, you can inspect all manner of status info and tables for a running firewall with pfctl, there must be an equivalent for ipfilter. If you are looking for general info about building a firewall, eg tcp and ip headers, plus icmp and voip and other protocols, then I would recommend the following tutorial, it has a huge amount of information - it is a lot more than just a tutorial on iptables. http://iptables-tutorial.frozentux.net/iptables-tutorial.html Lastly, the OpenBSD PF Packet Filter Book has been very useful for me, but I use pf where possible - I think it is the easiest, and paradoxically the most powerful of all packet filters, but that is my personal opinion, YMMV. Cheers, Tim. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IPv6 CVS
Hi all, Does anyone know if there are any IPv6 CVS servers for FreeBSD? (As in receiving the STABLE and ports branches) I currently use cvs.freebsd.org but it dosent have an record. Ta Peg dig cvsup4.freebsd.org ; DiG 9.4.2 cvsup4.freebsd.org ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 34684 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 6, ADDITIONAL: 0 ;; QUESTION SECTION: ;cvsup4.freebsd.org.IN ;; ANSWER SECTION: cvsup4.freebsd.org. 3600IN CNAME freebsd.isc.org. freebsd.isc.org.3600IN 2001:4f8:0:2::e ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Postfix problem.
Can you please cc: the mailinglist? Thanks. -On [20080714 15:36], Andres Chavez ([EMAIL PROTECTED]) wrote: postfix/postfix-script: warning: not owned by group maildrop: /usr/sbin/ postdrop postfix/postfix-script: warning: not set-gid or not owner+group+world executable: /usr/sbin/postdrop postfix/postfix-script: starting the Postfix mail system. I would suggest: 0) clean your system from your botched attempt at installing postfix by yourself 1) read http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ports-using.html 2) install postfix from ports/mail/postfix And take it from there? Hi there, I have attached the notes I gathered while making the postfix server that is sending you this mail. In particular, pay attention to the bit that says: As part of the installation the port asks if it could add user postfix to group mail, I advise answering yes. It also offers to activate postfix in /etc/mail/mailer.conf, again answer yes. Regards, Tim. We are BSD ... resistance is futile. http://www.freebsd.org/ - http://www.openbsd.org/ - http://www.netbsd.org/ postfix Description: Binary data ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sysinstall is still inadequate after all of these years
Robert Watson wrote: On Thu, 3 Jul 2008, Lothar Braun wrote: Robert Watson wrote: My primary concern about some of these replacement installer projects is that they've placed a strong focus on making them graphical -- I actually couldn't care less about GUIs (and I think they actually hurt my configurations, since I use serial consoles a lot), but what I do want is a very tight and efficient install process, which I feel sysinstall does badly on (not just for the reasons you specify). Hmm, how should a tight and efficient installation process look like in your opinion? And what are the other points that are bad in systinstall? For me, it's really about minimizing the time to get to a generic install from a CD or DVD. Most of the time, I don't do a lot of customization during the install -- I configure machines using DHCP, I add most packages later, and I tend to use default disk layouts since my servers don't multi-boot and the defaults currently seem reasonable. I don't like being asked many more questions than whether or not to enable sshd, and what to set the root password to. This means that I find our current distributions menu a bit inefficient (I don't want sub-menus, I just want checkboxes), and that the inconsistency in the handling of the space/enter/tab/cursor keys across different libdialog interfaces in the install is awkward. The current generic and express installs seem to capture a lot of my desire, in that I can get a box installed in 5m including actual time to write out the file systems, which is great. I really don't want to lose this with a new installer :-). What about having two utilities for the installation process? Something like a very small (non-gui/non-X) version of sysinstall that just installs a base system and only has the functionality to - partition/label a disk - configure the network (if needed for installation) - install the base system (or parts of it) - install a boot manager and a second utility sysconf that provides the other stuff like post installation system configuration (sshd, mouse), installing packages, etc. The second utility could have an X-based GUI without disturbing the installation process of serial console users or people that don't like X on their machines. Would that be a good idea? Best regards, Lothar I understand the desire to have an automated installer to make things real easy for first time installation for new users. But many people, including myself, will want to retain the current ability to specify exactly what we want as well. So, why not have a single menu at the start with 2 options: 1 - automatic desktop install (new user) 2 - traditional installer (veteran user) Perhaps the automatic installer can just use whatever disk space it finds (with suitable warnings) and attempt to install everything, ie equivalent of choosing All at the 'select distributions' stage. Maybe even do DHCP for net config. This would give a first time user a working system with a nice shiny X to make them feel good about choosing FreeBSD. Yes, I know they could just go to pcbsd, but I would prefer to have a new user at least attempt to learn proper sysadmin skills on vanilla FreeBSD. And if a new user gives up just because the installer is too confusing (especially the partitioner - it is wonderfully powerful, but it does take a bit of getting used to) then I think that is a shame. My adjust for current exchange rate cents. Tim. This email has been checked for viruses. It has sufficient. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
ICANN votes to expand domain name character set
Hi there, In case you haven't heard yet, ICANN have unanimously voted their approval to expand the domain name character set to include Asian, Middle Eastern, Eastern European and Russian character sets in domain names. In addition, top level domains will have their restrictions removed, ie any non-offensive top level domains will now be allowed. I'm guessing the inclusion of the new character sets will mean a fair amount of alteration to code that processes domain names. http://www.icann.org/en/announcements/announcement-4-26jun08-en.htm Cheers, Tim. We are BSD ... resistance is futile. http://www.freebsd.org/ - http://www.openbsd.org/ - http://www.netbsd.org/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
PXE on 7.0 problem and solution
Hi there, Installing 7.0 via PXE has a slight problem that is easily worked around. The file /boot/mfsroot.gz on the installation media needs to be unzipped to make PXE boot via tftp/nfs work. Otherwise the loader ultimately complains that it cant find the device to boot from. For example, if you have the installation media living at /usr/pxe/nfs/ on the PXE server, then do: gzip -d /usr/pxe/nfs/boot/mfsroot.gz After doing this it now loads the kernel and starts the installation procedure as expected. Someone more knowledgeable than me might want to let whoever needs to know about this. Apart from that, it looks great, the work is appreciated, thanks for the new release :-) Cheers, Tim. We are BSD ... resistance is futile. http://www.freebsd.org/ - http://www.openbsd.org/ - http://www.netbsd.org/ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Security Flaw in Popular Disk Encryption Technologies
--- Pieter de Boer [EMAIL PROTECTED] wrote: Jeremy Chadwick wrote: It's interesting that you classified this as a feature (in quotes), because there's nothing modern about said feature. This issue has existed since the beginning of RAM chip engineering; I can even confirm this feature exists on old video game consoles such as the Nintendo and Super Nintendo (where there were strict guidelines put in place by Nintendo, requiring developers to initialise certain areas of memory and certain memory-mapped I/O registers during hard or soft resets). I shouldnt've used the word 'modern', then. Proper software should be memset() or bzero()'ing memory space it mallocs. I've gotten in the habit of doing this for years, purely as a safety net. If said software doesn't do this, it's very likely succeptable. That is not relevant to the issue. The issue is that the keys are in memory when the encrypted filesystem is in use. The keys can be read by pulling and reinserting the power plug and restarting into a tool that can dump memory (or by placing the memory modules in another system). The keys to encrypted volumes can be found in this dump, leading to a compromise of the data. Many BIOS have fast and slow boot options - they are usually set to fast by default. The slow boot option often checks RAM and effectively wipes RAM in the process. If the BIOS is password protected then the only way to break in is to reset the BIOS by removing the BIOS battery. Given that RAM degrades over a short period of no power, and that arranging to physically pull the BIOS battery most likely exceeds that time limit, then this would effectively be one solution. Although it will mean always booting the slow way. Tim. Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Security Flaw in Popular Disk Encryption Technologies
--- Dimitry Andric [EMAIL PROTECTED] wrote: On 2008-02-23 02:08, Atom Smasher wrote: article below. does anyone know how this affects eli/geli? from the geli man page: detach - Detach the given providers, which means remove the devfs entry and clear the keys from memory. does that mean that geli properly wipes keys from RAM when a laptop is turned off? This is a physical attack, and there's nothing you can do in software to prevent it. Of course geli or other software can attempt to erase the keys from RAM as soon as it's done using them, but it won't prevent hijacking them beforehand. It's the same with all physical attacks: hardware sniffers, keyloggers, TEMPEST, etc. You need physical (hardware) protection to secure against these, not software. The cracking method relies on the ability to find the key in memory, so, if the key is obfuscated then this would mean the cracking method could no longer find the key even if it has access to memory. For example, create a series of random bytes of equal length to the key, lets call that the obfuscator. And now xor that with the key, lets call that the xord key. To use the enc/dec system an extra step would need to xor back to the original key. The idea is that real key is only created when needed for use, and then immediately overwritten after use. If the obfuscator and the xord key are stored in memory at unpredictable locations, ie dont just have them sitting next to each other, then this would make it much more difficult to _find_ the key as it would now involve identifying two groups of randomly located (in memory) bytes that are xor'd to create the real key. Yes, with sufficient reverse engineering it would be possible to find out where the obfuscator and xord key have been stored, but this would at least stop the relatively trivial search method being used in the paper. Just a thought, and yes, I have now actually read the paper. Tim. Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: firefox flash plug in woes
--- KAYVEN RIESE [EMAIL PROTECTED] wrote: i have been told that freeBSD does not go well with flash plugins for browsers, which is quite a ubiquitous technology in websites. is there any progress on this? i have freeBSD 6.2-STABLE and gnome desktop Hi there, I have native firefox with flash 7 working fine on FreeBSD 6.2, with java and adobe reader. Note I always install via ports, and they are up to date. Anyway, here is how, you can try it from packages, ie pkg_add -r x - hopefully that works too, but if it doesnt then installing from ports definately does. [ Note, I just copies/pasted this from my notes, there may be later versions of these packages you can also use - but IIRC I had some problems with them ] install www/firefox install print/acroread7 install java/diablo-jdk15 install www/linux-flashplugin7 kldload linux echo none/compat/linux/proc linprocfs rw 0 0 /etc/fstab mount -a echo linux_enable=\YES\ /etc/rc.conf nspluginwrapper -v -a -i Cheers, Tim. We are BSD ... resistance is futile. http://www.freebsd.org/ - http://www.openbsd.org/ - http://www.netbsd.org/ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Project Ideas and a question
--- David Naylor [EMAIL PROTECTED] wrote: Hi, The question first: init does allow a chroot before booting the system however does it allow the first device to be unmounted and use the new chroot as the root device. If it does how can that be achieved. My motivation for this: Allow a USB device or CDROM to boot the system, then init running of the removable device to execute a script that will allow the system to be setup (such as configure devices, setup gdbe and geli, etc) then when init chroot's it unmounts the removable device and allows that device to be physically removed. I have some project ideas (due to lack of technical skills I can not pursue them at this time but that is no reason not to share :-). If someone thinks an idea is a good one could you please add it to the appropriate location (the volunteer projects page???). My ideas: 1) Automatic module loading. Create a discovery system that upon identifying hardware that a module supports, loads the module. This would probably be a user-land implementation? Motivation: Additional ease of use (especially with sound) 2) Automatic kernel customisation. A tool that builds a custom kernel with all the devices for the current system builtin and with everything not needed removed. Motivation: Take the hard work out of building a custom kernel] 3) If question above is not implemented than add to idea list... Feedback is welcome. Thank you for listening to me. David Hello David, These all sound like great ideas, however they may have a better chance of being implemented on one of the sibling versions of FreeBSD, ie Desktop BSD or PC BSD. These offerings have already made quite large steps in regard to automating the installation of a BSD system. The general aim is to make it as easy as possible for someone unfamiliar with BSD to install a desktop, ie so it can compete with other desktop operating systems that are already very easy to install. By contrast, the native version of FreeBSD is put to many uses, often not involving a desktop, eg servers, routers, embedded systems. The ability to customize/tune pretty much all of the kernel/world is what makes this possible. And so having an automated installation would have to be unbelievably intelligent, and complicated, in order to cater for all these possibilities. Lastly, keep going with the new ideas, they are always welcome. Perhaps you may want to send them to [EMAIL PROTECTED] as this would seem to be more appropriate for initial ideas postings - and more people will see them as well :-) Kind Regards, Tim. Tonight's top picks. What will you watch tonight? Preview the hottest shows on Yahoo! TV. http://tv.yahoo.com/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: MS Vista vs FreeBSD's bootloader
--- Thomas Sparrevohn [EMAIL PROTECTED] wrote: On Thursday 28 June 2007 14:44:05 [EMAIL PROTECTED] wrote: --- Thomas Sparrevohn [EMAIL PROTECTED] ha scritto: ... I have Vista Home edition ruinning any FreeBSD without any problems and without having to do anything special - That is on CURRENT Hmm... Installation order is important, perhaps you already had FreeBSD before installing Vista? In my case Vista Premium came preinstalled, there was also a FAT partition (with diagnostic stuff) and an NTFS for rescue purposes. No - The originally came with XP - I nuked that and installed FreeBSD - However I did nuke the XP totally before upgrading to Vista - It does overwrite the FreeBSD MBR - I just rebooted using a CD and added the mbr again Of course getting the new computer without Vista was not really an option :(, but MS went too far this time, they removed postcript type1 font support and they crippled OpenGL enough that major CAD packages don't work easily or have something like 85% performance penalty. Pedro. --- Hi, this may not be the correct place to ask - but it is related. Has anyone been able to get Vista running on qemu? Cheers, Tim. Be a better Globetrotter. Get better travel answers from someone who knows. Yahoo! Answers - Check it out. http://answers.yahoo.com/dir/?link=listsid=396545469 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [patch] rm can have undesired side-effects
--- Daniel Valencia [EMAIL PROTECTED] wrote: Actually, I would like to support this motion... Thinking over the possible behaviours of -P is to sit in a room saying to delete or not to delete... If you think it over from a higher perspective, The UNIX Way (TM) is to have individual commands for specific tasks and to extract tasks from commands that have gotten too complex... and I think this is the case of rm... a shred command should be added that has the following behaviour: if the file is not writable, return with error. if the file has multiple links, and option -f was not specified, return with error. overwrite the file. optionally, unlink the file. Additionally, -P should either be rm'ed from rm, or added as a backwards compatibility hack that calls shred and returns with error every time the latter does. These are my 1.99 cents. - Daniel - Original Message From: Tim Clewlow [EMAIL PROTECTED] To: Bakul Shah [EMAIL PROTECTED]; Doug Barton [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; freebsd-hackers@freebsd.org Sent: Monday, October 30, 2006 12:20:33 PM Subject: Re: [patch] rm can have undesired side-effects --- Bakul Shah [EMAIL PROTECTED] wrote: Sorry if I tuned in late:-) I vote for taking *out* -P. It is an ill-designed feature. Or if you keep it, also add it to mv, cp -f ln -f since these commands can also unlink a file and once unlinked in this matter you can't scrub it. And also fix up the behavior for -P when multiple links. And since mv can use rename(2), you will have to also dirty up the kernel interface somehow. Not to mention even editing such a sensitive file can leave stuff all over the disk that a bad guy can get at. If you are truely paranoid (as opposed to paranoid only when on meds) you know how bad that is! If you are that concious about scrubbing why not add scrubbing as a mount option (suggested option: -o paranoid) then at least it will be handled consistently. What's the world come to when even the paranoid are such amateurs. -- bakul Based on all the potential situations where a -P option may possibly be implemented, is it worthwhile considering creating a command that just scrubs a file, and does nothing else. This would seem to fit the Unix paradigm of single command to do a single thing, and may be preferable to attempting to embed this function in every command that may possibly remove a file. Just my 2c Tim Having thought this over some more, if a shred/scramble/scrub command is created in its own right, then a number of new features could be added that do not currently exist. - The command could be writen to protect a single file, or, it could also write to an entire file system/media. - The command could offer many types of randomising possiblities, eg the current 0xff, 0x00, 0xff; or perhaps /dev/random could be written; or perhaps the user could specify exactly what is to be used to overwrite the file/file system - from memory some large organistations (govt depts) have specific rules about how files/file systems should be overwritten before old medie is thrown out and replaced (so no-one can scavenge the media and read sensitive data) Kind of thinking out loud here, apologies if its noisy, Tim. Everyone is raving about the all-new Yahoo! Mail (http://advision.webevents.yahoo.com/mailbeta/) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [patch] rm can have undesired side-effects
--- Bakul Shah [EMAIL PROTECTED] wrote: Having thought this over some more, if a shred/scramble/scrub command is created in its own right, then a number of new features could be added that do not currently exist. - The command could be writen to protect a single file, or, it could also write to an entire file system/media. These won't share much beyond what patterns to write and how many times. - The command could offer many types of randomising possiblities, eg the current 0xff, 0x00, 0xff; or perhaps /dev/random could be written; or perhaps the user could specify exactly what is to be used to overwrite the file/file system - from memory some large organistations (govt depts) have specific rules about how files/file systems should be overwritten before old medie is thrown out and replaced (so no-one can scavenge the media and read sensitive data) IMHO even this does not address paranoia very well. The point of rm -P is to make sure freed blocks on the disk don't have any useful information. But if the bad guy can read the disk *while* it also holds other files on it, the battle is already lost as presumably he can also read data in live files. If you are using rm -P in preparation to throwing a disk away, you may as well just use a whole disk scrubber. If you are using rm -P to prevent a nosy admin to look at your sensitive data, you will likely lose. He can easily replace rm with his own command. A separate scrub command may help since you can verify the data is erased. This is not to say rm -P or scrub is not helpful. If you know what you are doing it is perfectly adequate. But if you don't or you make mistakes, it will give you a false sense of security. For example, once a file is unlinked through some other means (such as mv) you don't have a handle on it any more to scrub. Basically you lost the ability to scrub your data due to a mistake. Worse, editing such a file may free unscrubbed blocks. A separate command won't help. This is why I suggested to have the system do this for you (through a mount option -- I don't care enough to want to implement it). Kind of thinking out loud here, apologies if its noisy, Tim. If the end result is clear headed go right ahead! Having cleared my head a bit more, I realise most of this can be done with consecutive runs of 'dd'. I think I've reached a conclusion here. Tim. Low, Low, Low Rates! Check out Yahoo! Messenger's cheap PC-to-Phone call rates (http://voice.yahoo.com) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [patch] rm can have undesired side-effects
--- Bakul Shah [EMAIL PROTECTED] wrote: Sorry if I tuned in late:-) I vote for taking *out* -P. It is an ill-designed feature. Or if you keep it, also add it to mv, cp -f ln -f since these commands can also unlink a file and once unlinked in this matter you can't scrub it. And also fix up the behavior for -P when multiple links. And since mv can use rename(2), you will have to also dirty up the kernel interface somehow. Not to mention even editing such a sensitive file can leave stuff all over the disk that a bad guy can get at. If you are truely paranoid (as opposed to paranoid only when on meds) you know how bad that is! If you are that concious about scrubbing why not add scrubbing as a mount option (suggested option: -o paranoid) then at least it will be handled consistently. What's the world come to when even the paranoid are such amateurs. -- bakul Based on all the potential situations where a -P option may possibly be implemented, is it worthwhile considering creating a command that just scrubs a file, and does nothing else. This would seem to fit the Unix paradigm of single command to do a single thing, and may be preferable to attempting to embed this function in every command that may possibly remove a file. Just my 2c Tim Low, Low, Low Rates! Check out Yahoo! Messenger's cheap PC-to-Phone call rates (http://voice.yahoo.com) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
