Re: /proc/pid/mem not working?
On Fri, May 02, 2008 at 03:13:13PM +0300, Shachar Shemesh wrote: Hi all, I'm having some strange time with /proc/pid/mem. The manual page says: /proc/[number]/mem This file can be used to access the pages of a process's memory through open(2), read(2), and lseek(2). Some digging through the internet reveals that that is, indeed, the case, but the process doing the reading must be attached to the process whose memory is being accessed as a debugger. Well, so far so good. However, when I go out to actually try it out (program at end of mail), I can access the file as neither read nor write. Any attempt to read from the file OR mmap it (PROT_READ or otherwise) results in invalid argument. I am running Debian Lenny with kernel 2.6.22-3-686. Any help appreciated. Gcc sign-extends the memory pointer into a possibly-wrong value when casting to off_t, which is signed. The subsequent read() therefore tries accessing an unmapped area in the victim process and fails. It also seems that /proc/pid/mem only supports read(). You need to change an #ifdef in fs/proc/base.c to support write(), and mmap() isn't supported at all. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: ptrace help
On Sun, Dec 09, 2007 at 07:59:59AM +0200, Shachar Shemesh wrote: You are leaving out the last two arguments of ptrace() in the parent, The man page says I'm allowed to do so in case the other arguments are not used. But they are. so they take garbage values, causing an unknown signal to be sent to the child. Try it with ptrace(PTRACE_SYSCALL, ret, 0, 0); Yes, that worked. What I don't understand, however, is why it worked. While the man page for PTRACE_SYSCALL mentions that addr is ignored (implying that data isn't), it does not actually tell me what the content of data is. For PTRACE_CONT, the man page says ``if data is non-zero and not SIGSTOP, it is interpreted as a signal to be delivered to the child''. It goes on to say that PTRACE_SYSCALL ``restarts the stopped child as for PTRACE_CONT''. Same for PTRACE_SINGLESTEP. When I tried writing 5 into data (i.e. - SIGTRAP) the next wait returns with Process exited with signal 5. It seems to be that when the data field is non-empty, the signal number I write there is actually delivered to the debugged process, but that is not documented in the manual, as far as I could see. See above. That's because ptrace(PTRACE_TRACEME) does not stop the process. If you want it stopped immediately after the ptrace() call, you need to do it yourself; e.g. send yourself a STOP signal. Is it being traced in any other reliable point? I now understand that the point it stops is when the first signal is being received, but I'm not sure whether exec guarantees that such a signal actually happens, or whether I should really send one myself. It's being traced, it's just not stopped. exec() is a special case, as documented: ``all subsequent calls to exec() by this process will cause a SIGTRAP to be sent to it''. If you want to catch system calls made before the exec() (like anything that printf() you added does), you need to explicitly stop the process. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: ptrace help
On Sat, Dec 08, 2007 at 11:50:17PM +0200, Shachar Shemesh wrote: In the parent I do: pid_t ret=waitpid(first_child, status, 0); ptrace( PTRACE_DETACH, ret ); ret=waitpid(first_child, status, 0); Instead of DETACH I already tried PTRACE_CONT and PTRACE_SYSCALL. What I expect to happen is that the child should run what I tell it to (I tell it to run echo hi), and be caught with both waits. Instead, the first wait catches a signal 5 (TRAP, as expected), but the second wait hangs forever AND THE ECHO DOES NOT RUN!! You are leaving out the last two arguments of ptrace() in the parent, so they take garbage values, causing an unknown signal to be sent to the child. Try it with ptrace(PTRACE_SYSCALL, ret, 0, 0); Also of interest is that when I added the printf after the TRACEME, that printf gets executed (output goes to the console) before the first wait at the parent. In other words, the program is not being traced immediately. That's because ptrace(PTRACE_TRACEME) does not stop the process. If you want it stopped immediately after the ptrace() call, you need to do it yourself; e.g. send yourself a STOP signal. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Quickest way to list content of directory(s)
On Thu, Feb 15, 2007 at 04:06:42PM +0200, Shachar Shemesh wrote: BTW, certain operations (atomic operations/counters/etc) -require- asm code. In an age where GCC, probably the least optimizing compiler among all popular compilers, is able to unroll loops and submit them, in parallel, to a vector processor (such as the MMX and its successors), I highly doubt that the above statement is true. I will also point out that some atomic operations are, actually, old legacy from the 8080 and 8086 days, and actually perform *slower* than their multi-instruction counter parts (the command loop is one example that comes to mind). Um, he was talking about operations like test-and-set or fetch-and-add. Even on architectures where they can be implemented purely in C, such implementations come at the cost of both performance and robustness. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Binding a process to a certain memory bank. (NUMA)
On Fri, Jan 12, 2007 at 03:32:08PM +0200, Gilboa Davara wrote: I know that I can bind an application to certain CPU set (in this case core0,1) using taskset. How can I make sure the same process only (as far as possible) allocates memory from the CPU0 memory bank? numactl(8) = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Login problem
On Sat, Sep 23, 2006 at 07:18:38PM +0300, guy keren wrote: foo / # chroot /chroot /bin/bash bash-3.1# ./bar foo / # ls bin boot chroot dev etc home lib lost+found mnt opt proc root sbin sys tmp usr var foo / # your program is flawed, and you didn't see it because you didn't check any errors in it, neither have you read the man page of 'chroot(2)'. according to the man page, chroot does NOT change the directory. you need to change it explicitly in your code. so your program did not create the so-called root jail properly. if you had added a 'chdir' into the new directory, and then did 'chroot .', then you'd have done your job (more) properly. Sigh. His program didn't create a chroot() jail, IT WAS BREAKING OUT OF ONE. Precisely as described in the chroot(2) manual page. Chroot jails are not safe against root. if you add error printings to your code, you'll see that your last execl fails with 'no such file or directory'. Huh? He showed you the output of his program. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: udp question
On Tue, Sep 05, 2006 at 11:58:39AM +0300, Erez D wrote: i did listen on both sides, if i use send, or write (from the server) i get : write: Transport endpoint is not connected if i use sendto, i get: sendto: Cannot assign requested address If you want to use send() or write(), you first need to use connect() on the socket, and specify the other side's address and port. Since this is on a datagram socket, the connect() just sets an association to the other side in the kernel, and doesn't cause any packets to be sent. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: diff regexps
On Wed, Jul 12, 2006 at 12:23:44PM +0300, Ehud Karni wrote: Last time I checked, $ in regexp meant match end of line. '$Id' would mean, if I understand this correctly, an Id coming AFTER the end of the line (an impossible combination, I know, but still). If I want grep to understand a literal $, I need to pass it a \$, which I can do either by doing \\\$Id or '\$Id'. I stand by my original statement. You are right. I'll say it again: YOU ARE RIGHT ! I take my statement back. Not quite. There are basic regular expressions and extended regular expressions. The $ means end of string only when used as an anchor. In basic regular expressions, the $ is an anchor only if used at the end of the regular expression. For extended regular expression, what Shachar said is essentially correct. Apparently, diff uses basic regular expressions. bash-3.00$ cat t1 $Id: clone.cc,v 1.27 2006/07/10 08:30:21 olegg Exp $; bash-3.00$ grep '$Id' t1 $Id: clone.cc,v 1.27 2006/07/10 08:30:21 olegg Exp $; bash-3.00$ grep -E '$Id' t1 bash-3.00$ = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: How can i tell if another process is writing to a file?
here's the situation: i have a file, and i want to open it only when no other process is writing to it. but i don't have control over the possibly writing process, so i can't do advisory or mandatory locking. basically, i want to treat a file received by scp only after the download is complete. of course i can write the file to /tmp or somewhere and then mv it to its destination directory when it's complete. but i was wondering if there's a more elegant soultion. If the temporary directory and the destination directory are not on the same filesystem then the mv won't be atomic. So for this to work you need to process the file after mv terminates, or you have the same problem all over again. Which begs the question, if you can mv the file after it's complete, why not just do your processing instead? = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: [OT] The people's salary survey
(This is the last message about this topic, thanks for your patience.) Last week I wrote: I want to create a detailed salary database, allowing people to see what others like themselves are earning. If you've ever looked for a job or even wanted to know where your current terms stand compared to the rest of the market, I'm sure you needed something like this. The link to the database (which is currently empty), and to more information is at http://www.cs.tau.ac.il/~adamx/salaries.html Since then there were approximately 300 visits to the site, but only 12 people sent in their data (I only got around to updating the site with 9 of them). For this site to have any value more people need to send their data, so if you think this sort of information would be useful, please contribute! If you don't want to bother with sending an email, you can do it via a form on the site (just remember that this isn't quite anonymous). = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
[OT] The people's salary survey
I want to create a detailed salary database, allowing people to see what others like themselves are earning. If you've ever looked for a job or even wanted to know where your current terms stand compared to the rest of the market, I'm sure you needed something like this. The usual salary surveys are insufficient. They don't differentiate between the wide varieties of skill sets: you are either a C++ programmer or an RT engineer. They also cater to the mediocre and not to highly skilled people. Asking friends and coworkers is also problematic. Most people don't have many clone friends with useful salary data. Worse, people don't like discussing what they earn. There is too potential for unpleasantness. To overcome these problems, I propose an anonymous salary database. You submit your salary data using an ANONYMOUS REMAILER. No one reading the mail (including me) will know anything about you except for what you choose you tell. If enough people send detailed enough data, we will have a database that should allow Linux device driver developers with 3 years of experience to find out how much they can expect to earn working at a startup, and many other questions. This will only work if enough people submit data. So if you like this idea, please send in your data! And forward this mail to wherever you think is relevant. The link to the database (which is currently empty), and to more information is at http://www.cs.tau.ac.il/~adamx/salaries.html I will also explain how to submit data here, in case people are worried that statistics are collected on those who access the above web page. Email your data to [EMAIL PROTECTED] using an anonymous remailer like https://riot.eu.org/anon/remailer.html. You don't HAVE to say anything except your salary, but in order for things to be useful please try to be as detailed as you can comfortably be. If you want, you can include a secret pass phrase which will not be displayed in the database; this will allow you update your entry. Here is a template of a detailed submission (of course you can provide even more information if you want): Salary: 15K plus car plus phone Hours: 160/month Job-Description: administering 30 Linux boxes, firewall and router Experience: 5 years Education: BSc in CS Skills: Linux, C, sh, python, perl, excellent knowledge of TCP/IP and security Organization-Type: startup Organization-Location: Tel-Aviv Secret: Supercalifragilisticexpialidociuos = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Kudos! [was Looking for an experienced Linux system administrator]
On Sun, Feb 27, 2005 at 12:05:21PM +0200, Jonathan Ben Avraham wrote: The average NIS58/hour + socials (which translates to NIS 81 total with socials factored in) is very low, also. Ouch. Poor samins. :-) I beg you to reconsider... Well... I know, I know. I saw worse, actually, but not by far. Look at the Horaat Shaa of the Chaskal. The prices that they are paying for Linux and other non-MSCE sys-admins is between NIS 92 and NIS 190. If that's what the contractor is getting, then the employee is getting a bruto of between NIS 46 and NIS 95 at most, including benefits but not car. That's how the majority of the market is working. There's a different way to look at this; according to these numbers, the system administration service is worth 17,020 to 35,520 NIS/month to the employer (taking your 185 hour work month). So when there is a direct employee on the receiving end --- not a contractor --- they can expect to receive anywhere between 13,500 and 28,000 NIS, gross, per month. (This is an approximation done by taking 25% employer overhead, instead of just the 20.33% of social benefits.) I admit that the majority of the readers of this list would probably command much higher pay, but they are not representative of the people out there actually doing sys admin. But it would seem that anyone here who is doing system administration work for a contractor and is out of their useless stage should do some thinking and see if they can find an organization that is regularly in need of 185 hours/month of system administration. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: threads question
To tell you the truth, I was counting on you, choo, specifically, when posting the message ;-). This solved the problem indeed. I did not invent passing a NULL pointer to pthread_create() - I lifted it from UNP as well. Apparently the thread library became less permissive since then. No, you stumbled upon a coding error which is corrected in the 3rd printing of UNP. See http://www.kohala.com/start/typos.unpv12e.html. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: sprintf, not sscanf, incompability
On Mon, 24 Jul 2000, Ury Segal wrote: char * sprintf( s, format, va_list); Oh. Yet another ANSI incompatibility from Sun Microsystems? You should probably forgive these guys. They were born before ANSI C and before POSIX. Modern BSD systems return int, as expected. This behavior exists in SunOS 4.x (and presumably earlier versions). Sprintf() returned `int' as far as the Seventh Edition release of UNIX from Bell Labs. This is noted in the documentation of SunOS 4.x, and indeed its stdio.h contains the following comment /* @(#)stdio.h 1.16 89/12/29 SMI; from UCB 1.4 06/30/83*/ The committee to standardize the C language was commissioned by ANSI on 1983. The work wasn't published until 1990. So what did you expect them to do, exactly? They chose one behavior and everyone followed. (Looking at CVS histories of BSD systems, they appear to have had `int' returning sprintf() at the early 1990s.) Historical artifacts not withstanding, there are many inter-operability problems that are caused because the standard bodies are too slow or confused (e.g. snprintf()) and so implementors just go ahead and do their own thing. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: The IGLU Cabal
[EMAIL PROTECTED] wrote: I've heard that there is something called the IGLU cabal, which controls IGLU, and makes all decisions. Who is on that cabal? The people on the cabal include myself, me, moi, men'ya, and min. Marc,, stop harassing the poor fool. There is no IGLU cabal. Oh my God, they got to Zadka as well! = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Alan Cox left to *BSD camp ?!
I just read Bezroukov guy article about Linus being bad boy http://www.softpanorama.org/People/Torvalds/Linus_Torvalds_biography.shtml And the sad thing is what he predicts becomes reality. As of 23-Feb-1999 Alan Cox is FreeBSD committer for VM. Um, it's not the same Alan Cox. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: The Myth of Open Source Security
AM Because they fixed so MANY holes, it isn't practical. What isn't practical, sending CC of CVS diff fixing the hole to maintainer of the tool? Or to bugtrack? Or publishing it on some page? If you seriously think that, then you don't have a clue as to the extent of the work the OpenBSD developers performed. The appropriate thing to do when you're generating large volumes of traffic is to set up a mailing list. Do you think that the bugtraq moderator would allow bugtraq to become a mirror for [EMAIL PROTECTED]? This information was always freely available; those who truly cared about security tracked it. Others apparently didn't -- so you believe that it was the responsibility of the OpenBSD people to flood them with it? = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: The Myth of Open Source Security
"Stanislav Malyshev a.k.a Frodo" wrote: What I don't like in OpenBSD is when someone discovers security hole they pop up and say "we've fixed it yet back in 1997". So why didn't you share it? Just to keep the claim of "most secure OS" or just because they don't care? Because they fixed so MANY holes, it isn't practical. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: (no subject)
Don't hold your breath; Contrary to kernel-based solutions (mainly Solar's Linux Kernel Patch from Openwall Project - http://www.openwall.com/linux/ ), this one deals only with some specific functions (e.g. strcpy) so it is not a general solution against buffer-overflows. In fact, it is even less general than the stack smashing portions of Solar Designer's Linux patches. Before you argue, let me say that by writing "general" I didn't mean that the kernel-based solutions *solve* the problem; You still can garbage the stack, but you can't execute it, so in the worst case, the victim process will fail, but no *real* damage will be caused to the system. What I meant was that it doesn't protect only specific functions, but ANY function. As was pointed here by Guy Cohen, there are ways to defeat the kernel level protections. To summarize, libsafe is as much a workaround as is Solar Designer's patch. Furthermore, its heuristics may prevent overwriting a function's stack frame, but they don't prevent overwriting sensitive data in local variables using a buffer overflow. (Similar techniques were used to exploit Sendmail a long time ago, only using global variables.) Linus and Alan Cox claim that preventing the stack from being executed is not a real solution but only a workaround, so they don't agree to insert it into the standard kernel. This is also why most of the distributions (I think except for Mandrake in its highest security level and Definite-Linux, as well as some security-focused distros) don't include the kernel-based solutions, but plan to include Lucent's solution. I think that this simply reflects their lack of technical sense, compared to Linux et. al. They are simply going for the most simple and unintrusive band aid. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Linux Firewall.
Another thing, If i have IP class 192.168.XXX.XXX no one can access to it from outside, right ? Isn't it secure by itself ? No one can access my workstations (or private servers) unless he is on the same network with the same ip class, right ? If you have a network that is not connected to the Internet, then no one can access it from the outside as well. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Microsoft Invents Symbolic Links
Sigh. I tried to make two basic points, both of which were apparently missed by most of the people who replied. "Stanislav Malyshev a.k.a Frodo" [EMAIL PROTECTED]: AM What most of you are missing in your zealotness is that the discussed AM service is based on reparse points, a new technology in Windows 2000. What you missing in your zealotness is that I'm not zealot and never was. So please hold you tongue and avoid sticking labels. AM This is a MUCH cleaner solution than using kernel modules that trap AM file-related system calls. It also, by design, allows several such AM modules to be loaded concurrently. In fact, it *is* using NT kernel modules to trap file-related calls, AFAIK. Only those modules are integrated. I am not interested in defending a technology I know very little about; that would be silly. In fact, it would be as silly as ATTACKING a technology I know nothing about. Yet, when the Microsoft press release was forwarded here, most of the posters here did just that. I was trying to show that any groundless attack can be countered by a different speculative argument. Only I took the time to read up a little about SIS, so what I said had something to do with reality. So these discussions, technically, are worthless; the act of starting such a useless discussion can be attributed either to cluelessness or zealousness. The following is a good example for this. AM That's a stupid assertion to make if you don't know what sort of AM hash they're using. Do you? Didn't they learn you in your math class that *any* hash that isn't equal by length with hashed objects will collide objects? It's called Dirichlet principle, IIRC - if you have 3 objects and 2 signatures, 2 objects must have identical signature. Think about it. Irrelevant. Can you even precisely DESCRIBE the following 1) the SIS file comparison algorithm 2) any other SIS algorithm 3) the exact usage they make of the ``fingerprint'' 4) the size of the ``fingerprint'' Or are you using a press release as the basis for your speculations? As it happens, the answer to 4) seems to be 128 bit. Without knowing the answers to 1), 2) and 3), you still can't assert that SIS is ``unusable for any serious data storage''. Moshe Zadka [EMAIL PROTECTED]: Please learn basic combinatorics. It doesn't matter what kind of hash they use. Please learn to read. Of course collisions are possible; that's not a matter of opinion. To assert based on this that SIS is ``unusable for any serious data storage unless it compares files bit-bit every time'' without knowing the kind of hash, and how it's used, is stupid. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Microsoft Invents Symbolic Links
OE storage of just one instance is something else. If you just symlink OE some files to a single file, and the owner of that file deletes it, OE you're screwed. What this thingy does is take care of all of that (again, Hardlink? What most of you are missing in your zealotness is that the discussed service is based on reparse points, a new technology in Windows 2000. I'm not a Windows guy, but the way I understand it is that a reparse point is a new file attribute which allows you to associate a kernel module with that file, so that this module is called when that file is accessed. Reparse points are also used by Microsoft in e.g. their distributed filesystem. This is a MUCH cleaner solution than using kernel modules that trap file-related system calls. It also, by design, allows several such modules to be loaded concurrently. I couldn't find information as to whether a file can be associated with more than one module; if this is indeed the case, then this is cool technology -- mainly because it works in a shipping product, compared to UNIX filesystem stacking implementations. Otherwise, it would greatly diminish the technical usefulness of this idea, and turn it into something of a system call trapping look-alike. Also, not that if hash is less than filesize, there's non-null chance that the signature will bind files that arem't identical - which means, it's unusable for any serious data storage unless it compares files bit-bit every time. That's a stupid assertion to make if you don't know what sort of hash they're using. Do you? = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: File Access Notification?
Let's say I want to know who (what process) accesses my .plan file. Or I want to know every time some process accesses my /etc/passwd. Every time a file, any file on my system, is accessed, I want to be notified. In what way can I accomplish this under linux? [...] The only way I see thus far is writing a kernel module which will fit in the VFS (Virtual File System) layer. The module will wrap all file access function calls with my own logging functions. Can anyone recommend a better, preferably user space solution? I doubt you can do it in user space. But it sounds like what you actually want it to wrap the open() system call. (If you're wondering what practical use this little project might have- I'm not really sure. But it seems like a fun excersise...) Security vendors and hackers have been doing this for years. I'm sure you can find sample code on the web. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Exploit (t666.c) breaking chroot()
This exploit for the latest Bind holes (hope you all upgraded to P5 already) promises to break chroot(). As I know, chroot shouldn't be returnable from by anyone. In many cases chroot is treated as a major security feature (think of linuxconf demo site, when they run their demo linuxconf from a chroot()ed environment) and many docs suggest running named chrooted. So how come it can be skipped? named is a root process; root can usually break from chroot() jails. The method used in that exploit is somewhat system specific -- they note, in fact, that is does not work against NetBSD -- but regardless, even if a root process is confined (from a directory tree perspective) to a restricted tree, it can still do a lot of damage. Summary: chroot() is not safe to use against a root process. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Legal stuf, GPL, ...
What I heard (and please note, this was from a programmer, not a lawyer) Just a note: I don't think that anyone's being a lawyer or not is relevant. AFAIK -- and I'd love to hear otherwise -- the GPL has not been tested in court. Thus, there are no REAL precedents on what can or cannot be done with GPLed software. So we can argue as much as we want, our opinions are more or less equally important. about the GPL in such matters is that contrary to popular belief, if I use GPLed code *I need not make my code GPL*. What I *do* need to do is to make the code *freely available*, under any free license. This of course does not mean that I can change the license of GPL components I am using; it means *my* portions of the code need not be GPL (but do have to be free). I don't see that at all. To wit: If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. (Where ``work'' is defined as ``either the [GPLed] Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language.'') So far, so good... BUT when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of THIS LICENSE. [emphasis added] It then goes on to exclude completely unrelated programs which are merely distributed on the same media as a GPLed program. In another message, wrt to an application using a GPLed component you claimed that the ``app as a whole could be distributed, say, with the BSD license''. That's specifically incorrect for the BSD license which has the great benefit of NOT requiring you to make copies of the source code available. It is further incorrect, I believe, because of the following clause from the GPL: You may not copy, modify, SUBLICENSE, or distribute the Program except as expressly provided under this License. [emphasis added] It does indeed seem that if you only use a GPLed interface without actually including it in your program, you don't have to publish your source code. This will often look unprofessional, if not be impossible; but OpenBSD does something similar to keep GNU bc(1) from printing the announcement required by the GPL for interactive programs. The reason I am writing this post, though, is that the point I bring is often overlooked, and lots of Stallman-haters out there tend to yell about the viral tendencies of the GPL while these don't really exist (at least not in this sense). Even if what you claim were true, there would still be a reason to, um, disagree with Stallman. The GNU GPL essentially claimed the word ``free'' to itself, while in fact it isn't. If someone wants to keep modifications of a GPL'd program to themselves, they can't. That's not very free. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: sparc linux/solaris binary compatibility
1) They named the new version of their operating system Solaris 2, and retroactively named SunOS: Solaris 1; ]...] By the way: Sun noticed that the confusion that arose from step #1 was not enough, and that some managers in the install base world still thought they knew what was going on. Appropriately, all versions of Solaris 2 are also (tada!) SunOS 5 (That is, Solaris 2.4 == SunOS 5.4). Sorry, but that's incorrect. Sun's operating system was ALWAYS named SunOS. When Sun changed their kernel to an SVR4-derived one, they bumped the major version of SunOS to 5. Justifiably, I think. The ``Solaris'' name refers to to SunOS 5.x, OpenWindows 3.x, ToolTalk, and some other stuff sold together. Solaris 1 IS a retroactive name for SunOS 4.1.x along with OpenWindows 3.0. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Legal stuf, GPL, ...
Interesting issue IMO. I'd like to pursue this a bit further... You all mentioned that I 'must' publish the source code if I use a GPL source code in my app. How hard must I work to publish this code? Is it enough to: 1. Write 'if you want the source code e-mail me' in the installation file or the docs? 2. Bury a statement like 'the sources are available in: ftp.bla.com' deep on the web site in nearly invisible letters? 3. Not say anything at all (but if someone asks, supply them the sources)? Remember the GPL is a legal document. I know the 'spirit' of GPL is different, but I'm curious about the formal part of it... Um, I think it's pretty clear: 3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following: a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.) I don't see how this matters, anyhow; if you don't want to publish your source code, it doesn't matter just exactly how you publish it. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Vulnerability in certain WU-FTP (versions up till 2.6.0) configurations(fwd)
Ely Levy wrote: [EMAIL PROTECTED] - the dangers of ftp conversions on misconfigured systems/ftpd (specifically wu-ftpd) [useless advisory deleted.] Is this really necessary? People interested in this should subscribe to bugtraq, or whatever. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Masquarading on a dialup connection
I'm almost sure and dont' kill me if I'm wrong that ssh works above the telnet protocol and not replacing it.. Uh, it works ``above the telnet protocol'' in as much as FTP, SMTP, or HTTP work ``above the telnet protocol''. maybe one day ssh would replace telnetd but meanwhile for comptibilty with the rest of the world telnted is still needed not mention that sniffing ssh isn't that impossible as you make it sound (altough I agree it is safter than telnet) Good observation; Internet traffic can be easily sniffed. Which is why implementing strong cryptographic measures is needed in order to protect Internet traffic from such passive attacks. For example, see e.g. IPSEC and oh, wait... SSH. Unfortunately, SSH v1 is vulnerable to some active attacks, SSH v2 suffers from licensing problems and IPSEC has its own problems. Is that what you were trying to say? = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Vulnerability in certain WU-FTP (versions up till 2.6.0)configurations(fwd)
Part of linux is its security believe it or not, almost everything we talk about I can find you some other mailing list that talk about it if it's about hardisk Ip masquarting ssh and even hebrew in linux has its own mailing list. You might want to read all those security news groups and screen them all but when there is a security bug or even normal bug relating subject that is my opinion anyhow.. and maybe we should discuss it over the list what people expect to see on this mailing list? and btw although that I'm sure part of the things we mail about doesn't interst you you shouldn't be that sure about them not interst others.. I don't that security is off-topic on this list. But I think that mindlessly reproducing material from other mailing lists is not very productive. What about kernel release announcements? Release news of popular new Linux software? Gatewaying the various Linux newsgroups here? They're all ``part of Linux'' but dumping all those sources here would swamp the mailing list to the point of uselessness. The fact that this mailing list is about Linux does not mean everything about Linux should be dumped here. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Interface status detection
True. It's a bug. KDE fires up licq automatically so I have never noticed this bug. Now how do we fix it (without checking for a process named 'licq' or anything like that. How do you make sure a fifo has someone on the other end?) OPEN(2) Linux Programmer's Manual OPEN(2) NAME open, creat - open and possibly create a file or device [...] ERRORS [...] ENXIO O_NONBLOCK | O_WRONLY is set, the named file id a FIFO and no process has the file open for reading. Or, the file is a device special file and no corresponding device exists. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: 15th Century French Castle for Sale (fwd)
This ``spam'' was sent to the mailing list on Sun, 21 Nov 199 16:20:37. An apology explaining that the message was sent here by mistake followed 1:06 minutes later. Yes. Apology is not enough. The point was that the vast majority of spam is not followed immediately by an apology from the spammer. So that message might not have been spam. The ``spam'' was sent using Mozilla, not the world's most popular bulk mail software. Yes. If you pay attention to headers of spam, you probably know that some spam messages are sent by using standard UNIX or Windows mailers and newsreaders. True. 15% of 1847 email spam sightings on news.admin.net-abuse.sightings were for spam that included an X-Mailer: header. (This figure can't account for spamware that tries to make its output look like a legitimate message, though.) So there's a good chance that message was not spam. It was sent by a subscriber; in fact, a quick archive search shows that this subscriber has posted ~11 message to the mailing list in the last year. (I.e. this is not a spammer who subscribed in order to bypass the posting restrictions.) Yes. Again, if you pay attention to headers of spam, you probably know that some spam has perfectly valid sender addresses. I also pay attention to the BODY of spam. Spammers don't spam to piss YOU off, they spam for a purpose; usually to make money. Their schemes are arguably stupid (e.g. MLM, or ``buy my product'' kind of crap), but that's why they spam -- the larger the target audience, the larger the chances of the spammer seeing measurable profit. That ``spam'' advertised a castle for sale for $1,100,000. How many people in the world are interested in a castle in France for that price? How many of them subscribe to linux-il? Hmm, perhaps that message wasn't spam. It's generally not very courteous or helpful to cc NATO like you did on a first spam complaint, even if it's legitimate; given the question marks on this one, do you really think it was appropriate? This sort of hysterical bullshit does not help the fight against spam. My opinion differs here. One of the reasons is that he probably sent this message to other people, who did not want to receive it. When you receive spam, you have good reasons to believe it was sent to others. After all, you don't know the sender and the spam's nature is usually obvious. But in this case, the sender was not anonymous and in fact indicated that the message was sent in error. So, what evidence do you have to support your conclusion that he also sent this message to ``other people, who did not to receive it''? Aside from that, I'm curious as to what other reasons exist for your apparent belief that complaining loudly about something that is probably not spam helps the fight against spam. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: mail problem (recreating original error)
This, of course, shows that xerox.com is blocking email from addresses in the DUL. The cause for confusion here is that YOUR machine seemed to believe that it was mail.netvision.net.il, and thus the bounce you received was from [EMAIL PROTECTED] To wit, notice the headers from your message which bounced: Received: (from doritb@localhost) by mail.netvision.net.il (8.8.7/8.8.7) id RAA00693 for [EMAIL PROTECTED]; Wed, 10 Nov 1999 17:52:06 -0500 Date: Wed, 10 Nov 1999 17:52:06 -0500 Compare these to the headers from your current message: Received: from dialup.netvision.net.il (IDENT:[EMAIL PROTECTED] [62.0.180.41]) by mailgw1.netvision.net.il (8.9.3/8.9.3) with ESMTP id DAA06790 for [EMAIL PROTECTED]; Thu, 11 Nov 1999 03:47:57 +0200 (IST) Received: from netvision.net.il (doritb@localhost [127.0.0.1]) by dialup.netvision.net.il (8.8.7/8.8.7) with ESMTP id SAA00898 for [EMAIL PROTECTED]; Wed, 10 Nov 1999 18:04:39 -0500 Notice that they are both running the same version of Sendmail in the same timezone, whereas the actual NetVision hosts are running a different version of Sendmail in a different timezone. So, DUL issues aside, I suggest that your machine is somehow misconfigured. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: mail problem
Nadav Har'El wrote: hours in the mail queue waiting to be sent. Anyway, when you send email directly from your dynamic IP, and the remote server does not answer, what do you do? You shouldn't give up, because the server may be temporarily .. The solution is to queue the mail and try again the next time you connect. Really? This is not an acceptable solution to me, and probably not to most people. I don't want to have to wait until the next time I log in (maybe only a day later) for the message to be sent! Of course, if someone deliberately *wants* to do that, then it's his choice, but at least don't tell me it's a useful thing to do :) In a world using the DUL, it would no longer be ``his choice''. Organizations should have a permanent and well-known IP, not one listed on DUL, which is exactly what the DUL phylosophy is: mailers should be accountable, and not completely anonymous. This is really poorly defined. 1) What's a ``mailer''? There are SMTP senders and there are SMTP receivers, and they are not always equal. 2) What's ``accountable''? Dynamic IP addresses for e.g. ISDN connected outfits can be first class Internet citizens for the duration of their connection by utilizing dynamic DNS. In such a configuration, incoming mail for such an outfit would be received at a directly connected host advertised via MX, and the queue would be drained when the outfit's mail host gets connected to the network (e.g. using ETRN). That aside, I find your point pretty upsetting. Configurations such as I describe are possible, in use where current technology allows, and otherwise are in demand. There are Internet Drafts dealing with exactly these issues. This was the also the case before the DUL; i.e. there is no technical argument as to why these setups are wrong. The DUL breaks such setups, and possibly others. And your justification is that this is ok, because organizations should not have IP addresses listed in the DUL? That's circular reasoning. ``The DUL says so'' is not a convincing argument. It means that if you choose to be anonymous, you're welcome to be on the Internet, but not to send *me* mail, because someone who sends *me* anonyumous mail is most likely a spammer. It's my choice to think that way and use DUL, and it may be your choice not to think that way, and continue to get a dozen spams per day. I'm not trying to convince YOU of anything. Had I been doing that, it wouldn't have been in a public forum. I'm trying to show that the DUL, as a technology to deal with spam, is broken and a bad design which -- if it becomes widely spread -- may impede the development of the Internet. This is bad. I know of people who reject any email with Hotmail, Yahoo, etc. addresses. It greatly reduces the amount of spam they send. Do you believe that this is a proper solution to spam? Would you advocate it? I hope not; it may be useful to one individual or another, but IT DOES NOT DEAL WITH THE PROBLEM. Neither does the DUL. As a sidenote, I use DUL,RBL,and ORBS for some time now and keep all discarded messages for research, and I never had a non-spam message discarded because of DUL - I.e., nobody ever seems to have sent me a message from a dailup-line without going through their ISP's SMTP server. So DUL false-positives are not as bad or as common as you make them sound. Uh, that's not very scientific. Do you usually make conclusions based on one data point? It's a nice touch using my own words agains me :) There's an important difference between Netvision and a government: if you feel Netvision's policies are too restrictive, you're free to use another ISP who doesn't block port 25. On the other hand, If you feel Israel's policies are too restrictive then, well, you're out of luck... Where would I go in a world where everyone blocked port 25? This is similar to the following: in a country with free speach, you're free to create your own newspaper, perhaps even by photocopying it yourself and delivering it to your subscribers. However, free speach does not imply that if you want to write something in, say, Yediot Achronot, then they *have* to let you write it there. They may charge you for it, place limits on it, or whatever they feel like. If you feel they are too restrictive, go to Maariv or open your own newspaper as described above. I really don't want to get into THIS. So think for yourself; if what you say is true, how exactly do you explain the brouhaha that happened when HADASHOT was closed? With all the Nimrodi scandals? We live in a world where NOT everyone can publish a newspaper. It is therefore the public's right (and duty) to protest when its watch dogs become corrupt, or when pluralism is at risk. Of course if the limits are arbitrary and too restrictive, the clients should protest to the ISP and threaten to leave. If all ISPs form a cartel and put limits
Re: Is Linux on the way of getting too complicated?
I wonder what is the figure for Linux if I would take into account the Xwindows interface and/or various libraries that meant to hide it. And what about the various window managers ? This figure is misleading anyway. Pure Unix has 5 system calls - open(), read(), write(), close() and fcntl(). And fcntl() hides 700 different things. Uh, no. (Btw, what's ``pure Unix''?) I'll ASSUME that you meant that you can abstract anything as a file, and thus lose most of the API; you'd still be wrong, since you've missed many file-related system calls (e.g. lseek(), truncate(), unlink(), etc.) The `everything is a file' architecture is present in the Plan 9 operating system from Bell Labs, and even that OS has a lot more than 5 system calls. I can imagine how you'd implement much of the UNIX API in terms of open() and friends, but that would not only be a very complex implementation, it'd in a very ugly API. That API wouldn't be any less complex than the `standard' UNIX API. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: mail problem
Actually, it's more of a philosophical question; the MAPS RBL only lists IP addresses which are associated with `hard' network abusers, e.g. bulk friendly ISPs, etc. So sites choosing to block traffic (or SMTP) from IP addresses listed on the RBL know fairly well that they won't lose real email. Not necessarily true -- bulk friendly ISPs can also have legitimate customers. I think you're wrong there. In spam-fighter lingo, a ``bulk friendly ISP'' is an ISP willing to tolerate its users sending unsolicited bulk email, which is one of the more common definitions for spam. (Although not all spam fighters agree on that definition.) The RBL lists such ISPs, if they have shown that they will tolerate customers who use their infrastructure to abuse the net. Web hosting outfits that host pages for spammers and refuse to remove them are also listed on the RBL, and I'm sure they have ``legitimate'' customers as well. The whole point of the RBL is to show pro-spam outfits that being pro-spam HURTS. The idea is that when the non-spamming customers notice that they've lost connectivity to large parts of the net, they will pressure the outfit to get out of the RBL. (Either explicitly or implicitly, by switching ISPs.) Getting out of the RBL means showing MAPS that the ISP no longer tolerates spammers. This is exactly why it is so HARD for an outfit to get on the RBL. The RBL is not as much a mechanism to protect your mailbox as it is an attempt to STOP spam. Spamming outfits don't get plonked into the RBL immediately; only after education attempts fail and an outfit is proven to be totally rogue will it be listed in the RBL. So when everyone and their wristwatch have their own IPv6 addresses we can stop using it. (For whatever reason.) It's wrong to force users to use their ISP's mail hubs, but having your mail server crumble under the load of spam isn't exactly right either, so each administrator decides on some compromise. I don't use either of these three systems, but I don't get a lot of spam. For some people it's better even to reject a legitimate e-mail once in a long while than to be unable to read it anyway because of all the spam. The right solution, IMHO, it to complain. Spam can be stopped if people complain. Otherwise, with all the black lists and filters in the world, you're just burying your head in the sand. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: mail problem
that isn't what always happens. Theoretically, users of the DUL accept the fact that they won't receive email from dynamic IP addresses. But, as we've just seen, not all dynamic IP users are spammers. I think the DUL is an inferior solution. Who says dynamic IP email is bad? What Someone has already posted here the correct explanation for why dynamic IP email *IS* bad, even when not considering the spam accountability issues described above: it is very often the case that remote mail servers suffer from lapses of inavailability: either because of network connectivity problems, because of shutdowns, and so on. Mailing list administrators are well aware of the fact, and you usually see messages hanging around for hours in the mail queue waiting to be sent. Anyway, when you send email directly from your dynamic IP, and the remote server does not answer, what do you do? You shouldn't give up, because the server may be temporarily down, but you can't retry later because the user may disconnect the connection to the ISP in a minute! The solution is to send the message through your ISP's server, which is connected to the Internet 24/7. The solution is to queue the mail and try again the next time you connect. I'm obviously not suggesting that every end-user send their mail directly from their node. But there is no technical reason NOT to do so, and moderately sophisticated users -- not to mention non directly connected organizations -- often choose do it. The DUL philosophy implies that doing this is in some way wrong, which is nonsense. will happen with IPv6? I also think that it's wrong to force users to use their ISP's mail hub. (Or worse; invisibly redirect SMTP traffic to that host.) What does IPv6 have to do with these issues? IPv6 addresses obtained using stateless address autoconfiguration are as anonymous as dynamic IPv4 address. Should they be blacklisted as well? That sort of defeats the purpose for one the IPv6 design goals. Blocking direct port-25 traffic is a very interesting anti-spam measure that I haven't seen implemented before, and while it may sound "bad" and anti-freedom, I can't see what harm it can actually do to "normal" users, not spammers. It does not just ``sound "bad" anti-freedom''; it IS. ... forcing law-abiding citizens a method of communication between themselves is completely contradictory to the freedom of speech principle. Sound familiar? It's an excerpt from message [EMAIL PROTECTED] which you sent to this list with regards to the Israeli encryption laws as you perceived them. I see absolutely no difference between that, and forcing people to go through an ISP's smarthost for mail. will get listed. The ORBS database also lists some hosts which relay mail only for e.g. the ORBS test machine, and so are NOT really a risk to the Internet. Sites using the ORBS database implicitly choose not This is not true. It is true. Have you any evidence that the ORBS testing methodology can discern whether a host is relaying just for them, or for the entire world? A machine cannot "accidentally" relay mail only for ORBS's test machines, and not to any other machine on the Internet. How can this happen??? Did I say ``accidentally''? I can configure my machine to relay mail only when that mail is submitted by the ORBS testing machine, in order to demonstrate that the ORBS technology is broken. My machine will get listed in the ORBS database, although it isn't a risk to the rest of the net. Btw, this has been done, and that machine got listed in the ORBS database. There's a different issue, of second-hand relaying, e.g., some ISP may have a client using their mail server (smarthost) and that client's mail server has an open relay: but this issue is solvable too if the ISP cared to solve it. It is the fact, that the ISP's smarthost is NOT an open to third-party relay. ORBS will still list it. (Though they now give the ISP some time to fix the problem before listing them.) ORBS has also listed ISPs who failed to receive their warning message because the ORBS robot sent it to the incorrect address. ORBS will list any open SMTP relay that uses other methods to protect from abuse (e.g. rate limiting). ORBS is as broken as the DUL, if for different reasons. (Btw, there are convincing arguments that the ORBS testing essentially amounts to spamming.) = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: mail problem
In spam-fighter lingo, a ``bulk friendly ISP'' is an ISP willing to tolerate its users sending unsolicited bulk email, which is one of the more common definitions for spam. (Although not all spam fighters agree on that definition.) What about solicited bulk email? A customer may quite legitimately send bulk emails to a gazillion people who specifically requested them. A non-commercial example: what if I run a mailing list on my computer and am connected through an ISP? Yeah, so? I said ``unsolicited bulk email''. I didn't say that mailing lists were bad. Just about any good thing in this world can be abused. The fact that there are people who abuse good ideas (good technology, good anything) shouldn't lead to prevention of legitimate use of the ideas (technology, etc). IMHO. That's sad but true, which is why if you run a mailing list and don't take the basic precautions to protect yourself from abuse then you're part of the problem. FWIW, outfits that run more traditional mailing lists (i.e., periodical newsletters telling you about their latest cool stuff) are considered to be spammers if they don't specifically request permission from people to send them email. Think about really bad cases - being spammed by an ISP, for instance. For quite some time I was being spammed by GeoCities (not a GeoCities account - the GeoCities themselves). Whom do you complain to about this? I complained to GeoCities many times, they never as much as acknowledged my emails. It stopped only after GeoCities were bought up. ;-) The question is, did they keep spamming you while you were complaining? Merely lack of response is not a crime, as long as the spam stops. Otherwise, it's a case for an RBL nomination. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: äðãåï: Re: What did I do right?
Alex Shnitman wrote: I don't know how exactly his configuration works, but FWIW if you're using shadow passwords from a Solaris server, a user cannot ypcat passwd.adjunct, only root can. And if you're going to authenticate users from a central service on the network, be it NIS or anything else, how can you prevent the sniffing problem? Short of using something totally different a la Kerberos, you can't. (Am I right that Kerberos uses a challenge-response scheme that alleviates the sniffing problem?) No, Kerberos is vulnerable to dictionary attacks against encrypted passwords as well. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: How to block telnet access.
To give an example, you don't need to know a lot to run OpenBSD. But the security people at OpenBSD do know what they're doing. (Notethat I'm NOT saying that OpenBSD is 100% secure.) then in your own words, openBSD is insecure (i.e. anything less then 100% is insecure)? See http://www.openbsd.org/security.html. Every OpenBSD release has had new vulnerabilities discovered in it. Sorry, I disagree. When something is properly designed and small enough, it is quite possible. (Like I noted earlier, these days ``properly designed'' probably means little reliance on vendor libraries and other possibly insecure software.) next thing you'l tell me that you can write a program that has 0 bugs... Stop being silly. There's no reason for a simple program to have bugs, unless the programmer was incompetent. and that you can 'inspect and secure' each and every line of source code in a system that runs a few internet services? that is, each and every one of the few 100K source lines (sorry - the kernel itself is over 1M lines today, thought most are for drivers you do not use). How do you get that idea? I said that it is possible to verify a program that is ``small enough''. This isn't magic. It's computer science and mathematics. The process of proving that a program is correct is impossible because the actual verification procedure will be complex enough to have bugs; in other words, as we've figured out already, we can't inspect the entire system. So, the solution is to implement the network services using applications that are ``small enough'' so we can comfortably review them. In practice, this means separating the ``service'' into smaller ``tasks'', each of which 1) Is coded securely. 2) Is small, so it can be inspected. (Which btw, also means that it is less error prone, because it's small.) 3) Does not trust the other tasks. Apart from the advantage gained in code complexity and the ability to analyze it, there's also the significant fact that if one of the tasks does get compromised, it does not affect the rest of the system. Finally, it is true that to be able to inspect the program, you have to replace much of the system-related fluff. Since a lot of system libraries are not coded securely, this is actually a win. (I already said this a couple of times, but then again I already said most of the stuff above.) Second, I'm trying very hard NOT to use terms like ``95% secure''. Partial security isn't. In other words, I don't believe that 95% or 50% are ``not the same thing''. They are. Insecure. but in a world where you cannot achive the 100%, still 95% is better then 50% (or you don't beleive in statistics of the chance of being attacked by a cracker that happens to land exactly on the security holes that exist in your specific system). What exactly is this ``world where you cannot achive[sic] the 100%''? What's the threat model? I specifically stated that I was dealing with a case where internal threats are not an issue; i.e. THERE ARE NO UNTRUSTED USERS. The design above works for this case, because 1) The application interacts with the attacker only through the network, making that relevant code the ``critial path''. 2) The attacker cannot influence the flow of the program except by using networked input, which was dealt with in (1). In this case, it is possible to achieve ``%100'' security. Compare this to the case of a setuid application, where verification is a much more complex and difficult process, since the attacker has much more control over the program's execution environment. In that case there is indeed no chance for a reliable solution, so we have to fall back to the `minimizing damages' approach, i.e. keeping abreast of new vulnerabilities and keeping our fingers crossed. But in mathematical terms, that isn't reliable; we are in a race that we can lose. I'm saying that in this specific threat model, it IS possible to design a reliable solution. The reasons this usually isn't done are not technical. They are either economical, in that it's cheaper to deal with the occasional break-in than to design and implement a secure solution, or that the threat model used (even if unintentionally) excludes sophisticated attacks. Like I previously wrote, if your threat model is that you are only facing unlucky script kiddies then what you're saying is fine. I'll just point out, for completeness, that your threat model has high chances of breaking. and remember - the system is secure if it was never broken to - not if it is impossible to break into it (because this second option is never true). This statement is false any way you look at it. 1) I have a FreeBSD box at home. It's not connected to the Internet. I have considered and rejected the possibility of the CIA breaking into my
Re: How to block telnet access.
In [EMAIL PROTECTED], [EMAIL PROTECTED] (Alexander L. Belikoff) writes: So?! Just make all SUID binaries mode 4750 belonging to some designated group (suid) and make only _trusted_ users members of that group. Of course, the untrusted guys will have problems changing passwords / running a mail queue on their own, but that is not such a big deal as having someone playing with a most recent root shell exploit. What about setgid programs? Assuming you count them as well, your blanket suggestion also makes it impossible to do lots of other things beside ``changing passwords / running a mail queue''. And it doesn't deal with security holes that don't stem from setuid applications. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: How to block telnet access.
The problem is that they are several teen agrees that will probably give away their passwords and very soon i will have the whole hacker world in my server. Since i must give them telnet (ssh actually) access and i can't restrict the servers witch the ssh will be from (they are using dailup) then i'm pretty much sure that my security will be broken. I will install the shadow system ASAP, and will change the passwords(in case they used a John the ripper on my old passwords) but still. Is there a way to control the server time and process that they are using ? So they could not simply run something that will crush my system ? Can i limit their access to the network ? So they could not use sniffy in order to sniff my passwords ? Sorry, but you are in trouble. If you have untrusted users on your system, then your security is broken by definition (and in practice). Theoretically, you could try to build a chroot() jail for them. Unfortunately, doing this correctly isn't quite trivial and does not protect you from all the threats. Worse, assuming these people need to get some work done, they'll need access to (potentially vulnerable) applications and directories and the `security' of the jail gets even worse. FreeBSD has a jail(2) facility for similar purposes, but even that isn't perfect. This appears to be a political problem, not a technical problem. Untrusted users on your system will lead to a security breach; the decision needs to be made as to what is more important. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: How to block telnet access.
Or Sagi wrote: So if you don't trust your internal users - DON'T give them accounts. Going from regular user to root is trivial and only a matter of time (even if you're superadmin). *every* computer connected to the net, or with users on it can be compromised. That's misleading. For any security discussion not to become silly, the relevant threat model must be defined. The threat model in this case, as I see it, has one main assumptions, namely that attacks will only be carried out over the Internet. Thus, we implicitly assume that the following are irrelevant: 1) Physical access. (This deals with all the armed guards related arguments.) 2) Specific identity and/or aggression of the attackers. (This deals with arguments like ``what if the CIA threatens to rape and kill all your kids unless you tell them the root password''). Given this, I do NOT agree that a system that is adequately protected from the network and has TRUSTED users ``can be compromised''. ``Adequately protected'', in this case, refers to allowing a very specific (and minimal) set of services to be reachable from the network. Because of their small numbers, they can be inspected and secured. the question is how hard is it. Assuming a decent OS, a decent sysadmin (Keeping himself *very* updated with security alerts (Bugtraq advisories, etc ... (I'd say cert, but cert hasn't been releasing anything worth reading for quite some time)), and a good enough setup --- compromising the security (even from the inside), The question in this case was specifically about ``from the inside''. So, in your scenario, what happens when someone exploits a newly announced problem before the admin manages to fix it? What happens when someone exploits a problem before it is even posted to bugtraq and friends? (You know, not everyone gets their information from bugtraq and the CERT. Especially hackers.) damage can be confined (Assuming you _do_ have other machines on your network). Confined in what sense? It's generally accepted that once attackers gain root, you've lost. (Even if root is gained in a jail of some sort.) But why give them shell accounts? Give them FTP access if you need file transfer. If they INSIST on having shell accounts, set up a special computer for them which will be sacrificial. Take for example a university setting. You need to give students accounts, and you most certainly don't trust them .. Funny, I was about to write something about how the risks of untrusted users can be minimized if they are so restricted that they become useless. But that isn't the case with students; they need to compile stuff, to use the network, etc. So in other words, university computers are not secure. In real life, this usually leads to one of the following scenarios: 1) The university's network is Swiss cheese. 2) The university's admins are constantly fighting hacker-related fires. 3) The university enforces strict usage rules (e.g., no external logins) thus reducing the number of potential attackers. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: How to block telnet access.
In [EMAIL PROTECTED], Or Sagi [EMAIL PROTECTED] writes: ``Adequately protected'', in this case, refers to allowing a very specific (and minimal) set of services to be reachable from the network. Because of their small numbers, they can be inspected and secured. They can be inspected and secured ? Take SSH, for example. (I'm assuming that some form of outside login is wanted. The main two alternatives are SSH, and various OTP schemes (be it s/Key, SecurID ..)). What about the recent Kerberos SSH hole ? I'm not aware of anyone exploiting it, but given sufficient time, trust someone to find a hole. The operative word being ``can''. You can't make a system secure as is, because it contains too much code and too much dependencies in the code to inspect. But if you minimize and compartmentalize the services you offer, you are in a position to inspect them and secure them. SSH is a good example for a bad program; it's bloated and buggy, just like Sendmail. No one is forcing you to use Sendmail, though; qmail does exactly what I said: it's designed securely, and it takes the system-related bloat out of the equation by implementing those functions itself. That's arguably not very pretty, but in light of software quality, that is what (sadly) has to be done. There's no public qmail-like replacement for SSH, but that's because nobody has released one; people apparently accept the risks involved. (Plus, in all honesty, SSH is not a security disaster like Sendmail is. It's just too big to comfort.) The point being, again, that you probably can't rewrite you entire system securely. But you can implement and verify a few select services. Assuming sufficient skill on the intruders part, there isn't much you can do. There are precautions you can take to make things harder, and to help you analyze things after the event happened (Tripwire/ the likes). Again, this relies on underestimating the attacker. Once root is broken, anything (Tripwire included) can be fooled. However, the basic issue here (IMHO), is - Compare the percentage of people able to compromise the security of a vanilla RH5.0/Irix 5.3/insert favorite insecure OS here from the inside, to the percentage of people able to compromise a Secure OS, properly set up ? That works for the specific case of dealing with unlucky losers. The moment your attacker is either skilled, or just plain lucky (i.e. manages to use the latest exploit in the small window of time before you patch your system) then you've lost. That's fine, but I just wanted to pointed out that you can have something more reliable. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: FreeBsd
In [EMAIL PROTECTED], Vadim Vygonets [EMAIL PROTECTED] writes: Well, ITYM "non-compliant". In fact, just yesterday I've read an article that says BSD is better because in Linux you have just Alan and Linus in full control of code, while in BSD it's full team. In most BSD systems, there is a "core team" which has write access to the source code, and other coders, whose only chance to submit their code to the OS is to give it to the member of the core team. Sounds nice to me, actually. Actually, most developers in BSD systems are not part of the ``core'' group. They are people who have proven to be willing, trustworthy and talented and were therefore granted access to the projects' development machines and CVS repositories. The ``core'' group is more like a board of directors, or technical management. FreeBSD, for example, has 177 people with commit privileges, but only 16 members in the ``core'' team. NetBSD has approximately 102 commiters and 6 ``core'' group members. There is some overlap in these numbers, plus not every committer is actually a developer. (Since these projects include documentation as well, FreeBSD at least has people who are only allowed to touch the documentation parts of the tree.) Only OpenBSD does not have a core group. In fact, OpenBSD came to life because of `violent disagreements' between Theo de Raadt and the NetBSD core group. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: FreeBsd
Yaron Zabary wrote: I've been using FreeBSD for a couple of years now. IMO, its strong points (compared to Linux) are: . Its networking code is better. This seems to be an argument flogged about greatly, but it REALLY depends on what you mean by ``better''. Performance wise, I don't know. It's hard to do good benchmarks and I haven't performed any. Plus, results change all the time. Cutting edge wise? I'd say that Linux appears to adopt changes faster than BSD does. But what does this really say? For example, in traditional BSD stacks, every TCP timing activity (RTO, delayed acking, etc) are based on heartbeat timers and are therefore coarse grained. Just a few days ago, FreeBSD commited changes to their tree that replaced these timers with callout wheel based timers, increasing the TCP timer granularity. Linux, IIRC, has had fine-grained timers forever. On the other hand, it's not exceptionally clear how big a win this is. In fact, some research indicates that fine granularity clocks may not be so great. I think the appropriate line is that BSD code is more stable than the Linux networking code. It is definitely more mature. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: FreeBsd
"Stanislav Malyshev a.k.a Frodo" wrote: YZ I've been using FreeBSD for a couple of years now. IMO, its strong YZ points (compared to Linux) are: I'm a bit surprised how many myphologized is a mind of an average advocate. What you say is "standard 'Linux sucks' advocate kit". As most "standart advocate kits", it's built on myths that or were true 5 years ago, or were always false. Sheesh, a question was asked and answered. No need to jump down anybody's throat. YZ . The development cycle contains all major OS parts. This means that when YZ you say FreeBSD 3.2, you are refering not only to a kernel, but also to YZ libc and most system binaries (such as ln, awk, grep etc). I know yet another system which has almost all system binaries intergated into the OS. I do not like that OS. Solaris? Developing an OS and developing awk is different things. I believe his point was that the kernel as a separate entity means very little. In most OS development models, development of the kernel and userland utilities are tightly coupled. This isn't the case in Linux. Linus Torvalds ONLY maintains the kernel. What was your point? YZ . Its UFS is more stable than ext2fs which optimizes like hell. See SGI's YZ initiative of donating XFS sources to Linux. Which one does optimize? Ext2fs uses asynchronous writes for metadata updates. This makes it very fast, but at expense of reliability (in case of a crash). And why donating XFS means UFS is better than ext2? I think I've lost your point here. It means that to SGI's mind, XFS is better than ext2fs. SGI is marketing XFS as fast, reliable, and scalable. Therefore SGI believes that ext2fs is missing one or more of these features. P.S. Could we bury this holy war now? If you want to promote BSD, get beyond pack of myths and *promote* it, not demote Linux. Saying "X is worse" is not the same as saying "Y is better". Think positive. Yes, exactly the approach Linux advocates use when advocating Linux as an alternative to Microsoft OSes. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: PPP over an Ethernet connection.
"Stanislav Malyshev a.k.a Frodo" wrote: s As it seems to me now, I will either have to start learning the s PPP source, or get myself another router. Router would be not bad :) If you can't or won't, you will have to make some PPP - or fool pppd into thinking that you have serial line (like writing gateway from /dev/ptyXX to your network card) or write your own PPP implementation... People, THINK. Suppose you managed to hack something like that, what good would it do? What would these ethernet frames look like on the wire? What would their `type' field contain? How would the PPP implementation know who it should send these PPP-over-ethernet frames to? Obviously, you can't just replace the point to point link the PPP implementation thinks it is using with a multi-point link and have it just work. RFC 2516 is an informational RFC published by UUNET and other companies involved with a similar setup to the one described in the original message. (In their case, they're interested in using PPPoE between customer' PC and *DSL devices on.) Regardless, from reading the original message, I seriously doubt this is what [EMAIL PROTECTED] is looking for. (I also doubt whatever device he's using supports PPPoE. It was published on February '99.) To comment on the original question, that setup as described looks rather convoluted to me. Has the ISP in question stated they offer such a service? = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: PPP over an Ethernet connection.
Valentin Ossman wrote: Obviously, you can't just replace the point to point link the PPP implementation thinks it is using with a multi-point link and have it just work. RFC 2516 is an informational RFC published by UUNET and other companies involved with a similar setup to the one described in the original message. (In their case, they're interested in using PPPoE between customer' PC and *DSL devices on.) PPP stands for Point to Point Protocol. This protocol can not be run on a shared bus network like Ethernet. It can only run on an interface like RS232 or other serial link. That might come as quite a surprise to the authors of RFC 2516, the companies offering PPPoE based products and the providers utilizing PPPoE. I don't see why you need PPP to run over Ethernet. If you will be more specific, I may be able to give you other solution then using PPP over Ethernet. If you've been following this thread, you should have all the specifics you need. Specifically, go read http://plasma-gate.weizmann.ac.il/Linux/maillists/99/08/msg00284.html FTR, I don't think PPPoE has anything to do with the question that started this thread. I was just correcting some people here. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: [Re: Linux on SunSparc]
Gal Goldschmidt wrote: I am not here to start an Holy war, but what so good about Solaris7? I just had to configure 7.2 and compered to RH6 it sucks. Just to configure the network I had to do unconfigure system and then reboot. Then you don't know what you are doing. Then somehow it desided to call itsellf %M, we serched and searched and found it ... /etc/nodename... That sounds like it was misconfigured. Sorry about this. Discussions about Solaris vs Linux may be appropriate, but groundless bashing (of any system) is never appropriate, imho. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Info about auditing
we are looing for information about auditing in linux esepcially the following topics: audit deamon audit file structure there is no audit daemon in linux (or in unix systems in general) in the full sense of the word - however, there is 'syslogd' - the system logger daemon. this daemon accepts messages from other processes, using the syslog() C library function (man syslogd, man syslog...), and writes them into log files, or prints them on the system's console, or dumps them - all this, based on the syslog.conf file, found in the /etc directory (man syslog.conf). the log files are traditionally kept in the /var/log directory (or /var/adm on some unix systems), but this may be changed by modifying the syslog.conf file. read the mentioned manual, and you'll get the full info (including the structure of the log files' records). Syslog is hardly an auditing facility. As a matter of fact, many systems have auditing capabilities. (Any system claiming to be `C2 complaint' has to have them, for example.) To answer to original question, the stock Linux kernel has no auditing capabilities. FWIW, there's an independant package to add auditing to Linux at: ftp://ftp.hert.org/pub/linux/auditd/auditd.tar.gz It includes kernel mods to some 2.0.x kernel (don't remember the exact value of `x') and an audit daemon. It's not very robust, though. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: NFS and IP filters
Alex Shnitman wrote: I'm setting up IP filters on a firewall, and I need to add rules that allow NFS mounting to pass through (don't worry, not from outside, between two parts of the network here). What ports do I need to open? You usually can't tell. I inherited the firewall setup from the previous admin with the following ports open: sunrpc, nfsd, 769 778. Now if I disable the filters, mount, and then enable them again -- it continues to be mounted and it works. However I can't do the mount without disabling the filters for a moment. What ports am I missing? And does anyone know what are ports 769 and 778? You're missing the mountd port. Mountd (like most RPC daemons) does not pick a specific port to listen on, but gets one assigned to it on each run by the system. It then registers that port with the portmapper (which always listen on the `sunrpc' port). When a client wishes to mount a filesystem, it consults the server's portmapper to obtain the port of its mountd, and only then calls mountd. Stateful firewalls (case in point: FW-1) typically solve this by parsing the portmapper traffic that goes through them and allowing traffic to ports returned in portmappers requests. (Note the tunneling opportunity here if the portmapper isn't trustworthy.) Some people rely on their systems being deterministic. That is, since mountd runs from the boot scripts, and the boot sequence is well known, then all things being equal it will always get the same port number assigned to it. That happens surprisingly often (e.g. the `secret' rpcbind port security problem), but can't be counted on. (And obviously it can't be counted on with systems that randomize port numbers like OpenBSD does.) I suspect that the entries you inherited for 769 are 778 are attempts to rely on mountd having these port numbers. That's obviously broken. The real solution is system dependent. Some versions of mountd allow you to set their port from the command line. Some will notice an entry for `mountd' in services(4) and use that. Some will do both. And conversely, some clients allow you to specify a mount(1) option with the server's mountd port. Unfortunately, this isn't a standardized area, so this really depends on how modern a system you're using. If you can wire down the mountd port in this manner, you can safely filter it. Otherwise, you need stateful filtering. If neither is available, you'll have to resort to non robust solutions, such as counting on the port number being the same across reboots, or opening up a port range. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: NFS and IP filters
Ariel Biener wrote: It just occured to me that one could run a script immediately after the portmapper and the rpc services are up to create a dynamic firewalls ruleset. [...] Now, assuming you have a static ruleset, you concatenate the ruleset from that awk command I did above at the beginning of the ruleset file before running /etc/rc.d/init.d/ipfw start Of course this breaks if you don't rerun it whenever the portmapper or mountd is restarted. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Short question
In [EMAIL PROTECTED], Ariel Biener [EMAIL PROTECTED] writes: Does anybody know a shell command that allows me to run something in the background immediately? Use nohup if you're using a Bourne shell (sh) descendant. Just use `' if you're using a C shell (csh) descendant. Both will terminate as soon as they are detached from the controlling terminal. Backgrounding jobs using `' require that the job be configured (compiled in that way) to ignore some signals from the controlling terminal, in order for them not to terminate when the controlling terminal is killed. Oh, really? A ``job'' is a process group. When a session leader (e.g. a shell) exits, the kernel checks whether there is a controlling terminal associated with its session. If so, the foreground process group of that terminal is signaled with exactly one ``signals'', SIGHUP. Shells without job control don't deal with process groups at all, and so all their children get SIGHUP'd when they exit. For these cases, nohup(1) simply invokes commands with SIGHUP ignored. (Obviously, if you run a program that independently installs a SIGHUP handler with `' under sh, that handler will get called when the shell exits, which may or may not be alright.) Shells with job control (csh descendants, bash, some incarnations of sh, etc) have, well, JOB CONTROL. Jobs are started in their own process groups, and the shell changes the terminal's foreground process group whenever a job is brought into the foreground (e.g. with `fg'). Therefore, the kernel won't send a SIGHUP to background jobs. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Short question
In [EMAIL PROTECTED], Ariel Biener [EMAIL PROTECTED] writes: Most things you run in the backround (like ftp, irc, and such) install their own handlers. ``Oh, really?'' % find /usr/src/usr.bin/ftp/ | xargs grep SIGHUP % And as for IRC, it EXITS on a SIGHUP. % find ircii-2.8.2 | xargs grep SIGHUP ircii-2.8.2/source/irc.c: (void) MY_SIGNAL(SIGHUP, irc_exit, 0); ircii-2.8.2/ChangeLog: handlers for SIGHUP/SIGTERM that call irc_exit(). In fact, you have to know for sure that the job you run has not installed a signal handler. What are you talking about? In my previous message, I explained why any program that deals with SIGHUP won't exit when executed from a shell without job control. If it was run with nohup(1), it will ignore the SIGHUP sent by the kernel and continue running. If it installs its own signal handler, that handler will be run; the program will exit only if its handler causes it to exit, e.g. IRC. With jobs run from shells with job control, the SIGHUP isn't sent in the first place. That's the correct way to do things, btw; why kludge around and disable a signal (nohup) when the kernel offers job control primitives to do what you want? Fortunately, modern shells have job control. So, practically, the job must: 1). not be interactive. Depends. If you expect to run something in the background and still be able to type input into it, that (of course) won't work. But expecting that is as reasonable as expecting a ^C you type to the shell to interrupt background jobs as well. As for output, as long as the terminal is there you'll see the output (unless the program notices its in the background and stops producing output). When the terminal goes away, the program will start getting errors on write()s to the terminal. Whether it exits or not at that point depends on how well it is written. 2). not install it's own handler. That has nothing to do with anything, unless the handler causes the program to exit. Which is why nohup is evil, imho. USE A SHELL WITH JOB CONTROL. If you can make sure that it answers these criteria, then it will work. (like backgrounding a matlab job). If you can't, then you'd better use nohup or screen. You said jobs run with nohup will ``terminate as soon as they are detached from the controlling terminal''. --Ariel P.S. Notice that I am more concerned in giving practical answers, than theoretical ones. Notice that I am more concerned with giving answers that are based on reality than incorrect ones. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Short question
In [EMAIL PROTECTED], Ariel Biener
[EMAIL PROTECTED] writes:
Second, ftp WILL exit when it loses the control terminal. Try it, from
bash or tcsh.
I explained this behavior previously.
When the terminal goes away, the program will start getting
errors on write()s to the terminal. Whether it exits or not
at that point depends on how well it is written.
Simply, if ftp attempts to receive input from the user and fails, it
exits. This is correct behavior, why should it stick around?
Therefore, when using a shell with job control, it's quite
straightforward to do the following:
ftp get big-file
150 Opening BINARY mode data connection for big-file (lots of bytes).
^Z
Suspended
% bg
[1] ftp
% exit
When ftp finishes the transfer, it'll exit by itself because of the
above mentioned condition. (It doesn't try reading from the terminal
while transferring the file.) Come to think of it, I've been doing
this forever!
Because ftp is run in a background process group, the kernel doesn't
send it a SIGHUP when the shell exits. Had you run something similar
from a shell without job control (which isn't as simple as the example
above, since you can't suspend and `bg' jobs in a shell WITHOUT job
control!), then ftp would die immediately when the shell exited.
In fact, most Unix utilities will exit when losing the control terminal.
If the application expects to get input, and it can't do so (because
it lost its terminal), I'd expect it to exit. Like I said, that's
correct behavior.
To decide based on observing this behavior that job control doesn't
work, which is basically what you were saying... that's quite a
stretch.
You are welcome to prove me otherwise, and this way I might learn
something.
I explained what's going on, twice.
Which part were you disputing, exactly?
The fact that background jobs started from a shell with job control
don't die when the shell exits?
bash$ sleep 666
[1] 31187
bash$ exit
Connection to linux-box closed.
% ssh linux-box
Last login: Wed Aug 11 19:00:46 1999 from vortex
You have new mail.
bash$ ps -p 31187
PID TTY TIME CMD
31187 ?00:00:00 sleep
Or my explanation of how job control works?
$ cat wrapper.c
#include sys/types.h
#include unistd.h
#include stdio.h
int
main(int argc, char **argv)
{
if (argc 3) {
fprintf(stderr, "usage: wrapper path args\n");
return (1);
}
if (setpgid(0, getpid()) == -1) {
perror("setpgid");
return (1);
}
if (execv(argv[1], argv[2]) == -1) {
perror("exec");
return (1);
}
/*NOTREACHED*/
}
$ gcc -o setpgid wrapper.c
$ ./setpgid /usr/bin/sleep sleep 666
9616
$ exit
Connection to solaris-box closed.
% ssh solaris-box
Last login: Wed Aug 11 11:23:52 1999 from vortex
Sun Microsystems Inc. SunOS 5.6 Generic August 1997
You have mail.
$ ps -p 9616
PID TTY TIME CMD
9616 ?0:00 sleep
$ sleep 666
9624
$ exit
Connection to solaris-box closed.
% ssh solaris-box
Last login: Wed Aug 11 11:33:52 from vortex
Sun Microsystems Inc. SunOS 5.6 Generic August 1997
You have mail.
$ ps -p 9624
PID TTY TIME CMD
$ exit
=
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
Re: Short question
In [EMAIL PROTECTED], Ariel Biener [EMAIL PROTECTED] writes: I was referring to something else completely, and thus this misunderstanding. To better explain. If you try backgrounding a process why it waits for input: host:~ ftp host ftp ^Z Suspended host:~ bg [1]ftp ftp host:~ newline [1] + Suspended (tty input) ftp ftp host:~ exit There are suspended jobs. host:~ kill -9 $$ Just remember, this has nothing to do with the kernel sending anyone signals. A stupid process can continue trying to read from its nonexistent terminal forever. This is an application issue, not a system issue. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: sh script Q
Ariel Biener wrote:
To all the helpfull people:
I don't care to participate in religious wars, which is basically what this
thread is about. But factual mistakes need to be corrected.
I believe that when you create shell scripts, they'd better be generic,
unless there is a special reason, and if there is, it should be documented
in the script. (like using functions, which work in bash/ksh, but not in
the generic /bin/sh on many OSs.)
I know "$variable" works on bash/ksh.
Sigh.
As long as we're trying to be ``generic'', how about consulting the original
sh(1) manual from the Seventh Edition release of the Unix OS, from (then) Bell
Telephone Laboratories. You know, the sh written by Steve Bourne.
Blank interpretation.
After parameter and command substitution, any results of
substitution are scanned for internal field separator char-
acters (those found in $IFS) and split into distinct argu-
ments where such characters are found. Explicit null argu-
ments ("" or '') are retained. Implicit null arguments
(those resulting from parameters that have no values) are
removed.
So just treat Vadik and I as purists.
The suggestions made here have been anything but ``pure''. The answer to the
original question is in the man page.
${parameter:=word}
If parameter is not set or is null set it to word; the
value of the parameter is substituted. Positional
parameters may not be assigned in this way.
This is from a SunOS 5 man page, with the following heritage.
.\" @(#)sh.1 1.68 97/05/09 SMI; from SVr4
.\" Copyright 1989 ATT
.\" Copyright (c) 1997 Sun Microsystems, Inc.
.\" All Rights Reserved.
.\" Portions Copyright (c) 1992, X/Open Company Limited
.\" All Rights Reserved
(It's also in the Open Group UNIX 98 specification. But the use of the colon,
which adds the null test is missing in the original Bourne shell.)
I think most people can settle for this. If you want to be outrageously
``generic'' you can use "$VAR" or x$VAR. Using them both works too, but since
we're analyzing the ``best'' way to do something, it's just plain...
unnecessary.
Re: sh script Q
Ariel Biener wrote:
Which will result in the script fo fail if $PARAM is undefined.
Vadim's suggestion wasn't just a matter of semantics.
--Ariel
Vadim Vygonets [EMAIL PROTECTED] writes:
[ "$PARAM" != "SOMETHING" ] || {
;}
I think that it's better to do:
if [ "X$PARAM" != "XSOMETHING" ]; then .
Yes you right it's more unix, but i usually use the "$PARAM" !=
"SOME".
Hmm.
$ test "$FROB" != "" || echo "frob!"
frob!
$
Hrmph.
Re: I'm probably missing some c headers, but what ?
Orr Dunkelman writes: Oded, I strongly recommend on using other function the the given crypt function. In unix there are two crypt functions - one uses ENIGMA, the german rotor machine used in the second world war, the second uses a variant of Date Encryption Standard (DES). There's a command, crypt(1) which implements an algorithm designed along the lines of Enigma. This functionality is not available in a library function, AFAIK. Enigma was broken in the 40's, and is very unsecure (UK and USA could have broken the enigma encrypted messages without computers... today it's more the trivial). There remain still unbroken Enigma messages. Enigma is vulnerable to known-plaintext attacks, and this is how most messages were broken. (This is also the attack that CBW, the Crypt Breakers Workbench implements.) There are published ciphertext-only attacks against it, but they are practical only against long (i.e. longer than the ones in WWII) only. Don't get me wrong though, because of the known-plaintext vulnerability and the otherwise requirement for short messages, Enigma is not a good choice for a cipher today. DES is considered to be a very weak encryption function. It uses 56 key bits (you give it up to 8 byutes - 64 bits), and therefore considered weak. Last time I've checked a DES mmachine broke DES in about 22 hours. Just to give you a ratio, 64 bits encryption is passe, it is considered on the edge of safty (each new key-bit, multiply the time needed to the breaking phase by 2). Just so there's no mistake, this is simply a problem with DES key size that makes it vulnerable to brute force searches using advanced hardware and high parallelism. In fact, 3DES (which is roughly ``encrypt 3 times using DES'', establishing a 168 bit key) is the currently recommended encryption method by the IETF and banking standards. Regardless, standard crypt(3) implements a modified algorithm, which changes slightly depending on the password. One of the main reasons behind this ``salting'' of the hash was to defeat hardware attacks. The problem with crypt() is general is not in the strength of the algorithm, but the fact that users tend to choose weak passwords.
Re: [Fwd: Re: Please, put a fscking bullet in my head!]
Vadim Vygonets wrote:
I've always thought that it was quite distasteful of the Hebrew University's
sysadmins to quote user emails they receive on asr to mock them, but that can
probably be attributed to the basic problem I have with asr.
The user e-mails we quote have their names replaced with
something meaning{less,ful}.
That's inaccurate at best, but also irrelevant for this list. I'm taking
this off the list.
Apart from that, the ASR FAQ
mentions that if you don't like admins bashing you in public,
don't read ASR.
And yes, I agree that many people feel bad about this group. And
yes, I agree that the bashing that happens there is not nice.
And yes, I agree that this posting of mine was not nice, either.
That really goes without saying.
Don't get me wrong, though; I couldn't care less what you think of me.
However, since no one was in that thread for the girlies and the money, I
think it was worthwhile pointing out that arguing with you was essentially
futile.
Maybe it will. Flame wars do lead to something sometimes, as I
said in the message I posted to the list several minutes ago
(subject "Admin: proposal"). BTW, please read it, maybe you'll
like this proposal.
Yeah, it works for me. Too bad about the negative vibes this issue has
caused.
Re: Administrivia (was Re: äöòä äòöä)
Vadim Vygonets wrote: Another suggestion: make submissions allowed only to the list subscribers. Of course I'll do it. Please reconsider. Spam does suck, but there are other methods of dealing with it, and this prevents several common configurations from using the list.
Re: Administrivia
Evgeny Stambulchik wrote: Please reconsider. Spam does suck, but there are other methods of dealing with it, and this prevents several common configurations from using the list. Which configurations? BTW, the restriction should be based on the "From:" header (not "From", as it used to be for a short period of time when Ariel enabled it). Any configuration in which the address that eventually gets stuck in the From: header differs from the one used to subscribe to the list (or to generally receive email). Think about it, are you really not interested in what non subscribers have to say? What about the (admittedly somewhat farfetched) case in which Linus Torvalds wants to tell the list something but can't because he isn't subscribed? And what about a non subscriber who was cc'd to a message sent to the list but can't reply back to the list? Like I said, to defeat spam there are other methods. No need to kill a fly with a sledgehammer.
Re: FTP access for users ?
Alex Shnitman wrote: PS. I hope you're aware that enabling non-anonymous ftp access not inside a firewalled network is basically equivalent to putting all your users' passwords in the plain text format and sending it to a ... er ... mailing list :) Do you mind elaborating on this issue? Unless the users are chrooted, they can grab your password file. And regardless, eavesdroppers can sniff their passwords when they ftp in.
Re: mail problem
Just like MAPS RBL and MAPS ORBS. ORBS is not related to MAPS. You just choose which level of spam protection you want on your mail server. For low risk you can do none or just MAPS RBL, if you want more protection you can use ORBS, and if you're really desparate you also use DUL. You're sending e-mails directly from your dialup-line because *most* hosts aren't desparate enough to use DUL. Some are, though, so you better configure your mailer to use your ISP's mail relay. Actually, it's more of a philosophical question; the MAPS RBL only lists IP addresses which are associated with `hard' network abusers, e.g. bulk friendly ISPs, etc. So sites choosing to block traffic (or SMTP) from IP addresses listed on the RBL know fairly well that they won't lose real email. The DUL lists dynamically assigned IP addresses. It's supposed to list only address blocks which were submitted to MAPS by their owner, but that isn't what always happens. Theoretically, users of the DUL accept the fact that they won't receive email from dynamic IP addresses. But, as we've just seen, not all dynamic IP users are spammers. I think the DUL is an inferior solution. Who says dynamic IP email is bad? What will happen with IPv6? I also think that it's wrong to force users to use their ISP's mail hub. (Or worse; invisibly redirect SMTP traffic to that host.) Lastly, the ORBS database lists open SMTP relays. Even if a relay has never been used for net abuse purposes but ORBS finds out about it, it will get listed. The ORBS database also lists some hosts which relay mail only for e.g. the ORBS test machine, and so are NOT really a risk to the Internet. Sites using the ORBS database implicitly choose not to receive email from such hosts, and thus can lose mail. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
