bind(2) sets errno to undocumented EAGAIN?
Under what conditions does bind(2) set errno to EAGAIN? The 3.2R bind(2) manual page does not list that as a valid value for errno when bind returns -1. This came up when using http_load (http://www.acme.com/software/http_load) to stress-test a local web server. In other words, using http_load to test a web server running on the same machine. Debugging a bit, I determined that a call to bind in http_load.c returns -1 and sets errno to 35 (which is defined as EAGAIN in /usr/include/errno.h). Using ktrace/kdump, 522 http_load CALL socket(0x2,0x1,0x6) 522 http_load RET socket 4 522 http_load CALL bind(0x4,0x805f404,0x10) 522 http_load RET bind -1 errno 35 Resource temporarily unavailable What resource is unavailable? Charles To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ARPs on a bridge
Is there a way to force a Freebsd system to route to the same logican IP network rather than send a redirect? The situation occurs with segmented bridges where customers on the same logical IP network are on separate bridge groups. When trying to reach one another, they are getting redirects however they are not permitted to arp across groups. ... (long explaination moved to the end)... I think i don't understand the architecture of the system, so could you explain a bit more about that -- i would like to learn more about this. How many physical and logical interfaces does the FreeBSD system see ? From your description this is what i understand: customer [ DSL bridge ]--+[ main router ]-- rest of net. | customer [ DSL bridge ]--+ | repeat 150 to 900 times | shared frame relay without | multicast/broadcast support customer [ DSL bridge ]--+ and the understanding is that the 'DSL bridge' is perhaps implemented with a FreeBSD-based box with an ethernet on the customer side and a suitable card on the other side. Now if the DSL bridge is "almost" a bridge (in the sense that it filters broadcast traffic) then your architecture "almost" works (except when operation depends on traffic that you filter) and you need a separate mechanism to implement the functionality killed by the filtering. E.g. recognize that some broadcasts (e.g. ARP) are special and need to be forwarded anyways... cheers luigi On a DSL bridge you have 150 to 900 customers bridged on a relatively low bandwidth line (frame relay in this case). Forwarding broadcast traffic is very undesireable as you have to replicate the packet 900 times, and since you know the IP assignement for the DLCI you dont need to forward it to everyone. Each customer is on a different bridge group so traffic cannot be bridged between them, so you have to route, but you dont want to have to allocate a subnet to each bridge group either. The problem is that, from the FreeBSD boxes view, you are routing to the same logical net (assuming that all of the bridge groups are in the same IP space. We're not talking about bridging a couple of ethernets here. Dennis To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: On pthreads [Was: Re: I was accepted to LokiHack '99 at Atlanta Linux Showcase]
On [19991006 04:02], Brian F. Feldman ([EMAIL PROTECTED]) wrote: What do you all think about http://www.FreeBSD.org/~green/OpenBSD.libc_r.cancel.patch ? I isolated the set of commits that added cancelling to OpenBSD's libc_r, and it seems (since they took it from us originally :) it should be relatively simple to port :/ I knew you were working on importing the OpenBSD pthread_cancel. Any idea how much fun it will be to get this into FreeBSD? -- Jeroen Ruigrok van der Werven/Asmodai asmodai(at)wxs.nl The BSD Programmer's Documentation Project http://home.wxs.nl/~asmodai Network/Security SpecialistBSD: Technical excellence at its best All for one, one for all. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
New command for cdcontrol(1)
I'm using this patch for cdcontrol(1):
cdidPrint the xmcd's CD id.
--- cdcontrol.c.origSun Aug 29 18:40:16 1999
+++ cdcontrol.c Wed Oct 6 12:01:35 1999
@@ -33,6 +33,7 @@
#include sys/file.h
#include sys/cdio.h
#include sys/ioctl.h
+#include sys/types.h
#define VERSION "2.0"
@@ -65,6 +66,7 @@
#define CMD_RESET 12
#define CMD_SET 13
#define CMD_STATUS 14
+#define CMD_CDID15
#define STATUS_AUDIO0x1
#define STATUS_MEDIA0x2
#define STATUS_VOLUME 0x4
@@ -93,6 +95,7 @@
{ CMD_STATUS, "status", 1, "[audio | media | volume]" },
{ CMD_STOP, "stop", 3, "" },
{ CMD_VOLUME, "volume", 1, "l r | left | right | mute | mono | stereo" },
+{ CMD_CDID, "cdid", 2, "" },
{ 0, }
};
@@ -112,6 +115,7 @@
int open_cd __P((void));
int play __P((char *arg));
int info __P((char *arg));
+int cdid __P((void));
int pstatus __P((char *arg));
char*input __P((int *));
voidprtrack __P((struct cd_toc_entry *e, int lastflag));
@@ -252,6 +256,12 @@
return info (arg);
+ case CMD_CDID:
+ if (fd 0 ! open_cd ())
+ return (0);
+
+ return cdid ();
+
case CMD_STATUS:
if (fd 0 ! open_cd ())
return (0);
@@ -739,6 +749,92 @@
printf ("No volume level info available\n");
}
return(0);
+}
+
+/*
+ * dbprog_sum
+ * Convert an integer to its text string representation, and
+ * compute its checksum. Used by dbprog_discid to derive the
+ * disc ID.
+ *
+ * Args:
+ * n - The integer value.
+ *
+ * Return:
+ * The integer checksum.
+ */
+static int
+dbprog_sum(int n)
+{
+ charbuf[12],
+ *p;
+ int ret = 0;
+
+ /* For backward compatibility this algorithm must not change */
+ sprintf(buf, "%u", n);
+ for (p = buf; *p != '\0'; p++)
+ ret += (*p - '0');
+
+ return(ret);
+}
+
+
+/*
+ * dbprog_discid
+ * Compute a magic disc ID based on the number of tracks,
+ * the length of each track, and a checksum of the string
+ * that represents the offset of each track.
+ *
+ * Args:
+ * s - Pointer to the curstat_t structure.
+ *
+ * Return:
+ * The integer disc ID.
+ */
+static u_int
+dbprog_discid()
+{
+ struct ioc_toc_header h;
+ int rc;
+ int i, ntr,
+ t = 0,
+ n = 0;
+
+ rc = ioctl (fd, CDIOREADTOCHEADER, h);
+ if (rc 0)
+ return 0;
+ ntr = h.ending_track - h.starting_track + 1;
+ i = msf;
+ msf = 1;
+ rc = read_toc_entrys ((ntr + 1) * sizeof (struct cd_toc_entry));
+ msf = i;
+ if (rc 0)
+ return 0;
+ /* For backward compatibility this algorithm must not change */
+ for (i = 0; i ntr; i++) {
+#define TC_MM(a) toc_buffer[a].addr.msf.minute
+#define TC_SS(a) toc_buffer[a].addr.msf.second
+ n += dbprog_sum((TC_MM(i) * 60) + TC_SS(i));
+
+ t += ((TC_MM(i+1) * 60) + TC_SS(i+1)) -
+((TC_MM(i) * 60) + TC_SS(i));
+ }
+
+ return((n % 0xff) 24 | t 8 | ntr);
+}
+
+int cdid ()
+{
+ u_int id;
+
+ id = dbprog_discid();
+ if (id)
+ {
+ if (verbose)
+ printf ("CDID=");
+ printf ("%08x\n",id);
+ }
+ return id ? 0 : 1;
}
int info (char *arg)
--- cdcontrol.1.origSun Aug 29 18:40:15 1999
+++ cdcontrol.1 Wed Oct 6 12:04:42 1999
@@ -129,6 +129,9 @@
.It Cm info
Print the table of contents.
+.It Cm cdid
+Print the xmcd's CD id.
+
.It Cm status
.Op Ar audio | media | volume
--
Sergey Shkonda [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Release 4.0-current snapshot ?
Problem with release buid breaking at kdump. ( MDF_ACTIVE' redefined - making troubles ) Real problem probably ( ioctl.c:4: sys/device.h: No such file or directory ) -- === usr.bin/kdump cc -nostdinc -O -pipe -I/usr/src/usr.bin/kdump/../ktrace -I/usr/src/usr.bin/kdump/../.. -I/usr/obj/usr/src/tmp/usr/include -c /usr/src/usr.bin/kdump/kdump.c /bin/sh /usr/src/usr.bin/kdump/mkioctls ioctl.c In file included from :48: /usr/obj/usr/src/tmp/usr/include/sys/memrange.h:16: warning: `MDF_ACTIVE' redefined /usr/obj/usr/src/tmp/usr/include/pccard/cardinfo.h:77: warning: this is the location of the previous definition cc -nostdinc -O -pipe -I/usr/src/usr.bin/kdump/../ktrace -I/usr/src/usr.bin/kdump/../.. -I/usr/obj/usr/src/tmp/usr/include -c ioctl.c ioctl.c:4: sys/device.h: No such file or directory In file included from ioctl.c:76: /usr/obj/usr/src/tmp/usr/include/sys/memrange.h:16: warning: `MDF_ACTIVE' redefined /usr/obj/usr/src/tmp/usr/include/pccard/cardinfo.h:77: warning: this is the location of the previous definition *** Error code 1 Stop in /usr/src/usr.bin/kdump. *** Error code 1 Stop in /usr/src/usr.bin. *** Error code 1 - Any suggestions ( probably have to check out the sources again , hey ) begin:vcard n:Kruger;Johan tel;cell:+27 83 3015923 tel;fax:+27 12 6651343 tel;home:+27 83 3015923 tel;work:+27 12 6651338 x-mozilla-html:FALSE org:Nanoteq;Development version:2.1 email;internet:[EMAIL PROTECTED] title:Mr adr;quoted-printable:;;P.O BOX 12872=0D=0AOnderstepoort=0D=0A0110=0D=0ASouth Africa;Pretoria;Gauteng;0110;South Africa x-mozilla-cpt:;0 fn:Johan Kruger end:vcard
Re: On pthreads [Was: Re: I was accepted to LokiHack '99 at Atlanta Linux Showcase]
Jeroen Ruigrok/Asmodai wrote: On [19991006 04:02], Brian F. Feldman ([EMAIL PROTECTED]) wrote: What do you all think about http://www.FreeBSD.org/~green/OpenBSD.libc_r.cancel.patch ? I isolated the set of commits that added cancelling to OpenBSD's libc_r, and it seems (since they took it from us originally :) it should be relatively simple to port :/ I knew you were working on importing the OpenBSD pthread_cancel. Any idea how much fun it will be to get this into FreeBSD? Did they make any changes to libc? Some of our libc routines make internal calls to cancellable routines and shouldn't be cancellable in that case. Here's what POSIX states are cancellable routines: Required cancellation points: aio_suspend(), close(), creat(), fcntl()*, fsync(), mq_receive(), mq_send(), msync(), nanosleep(), open(), pause(), pthread_cond_timedwait(), pthread_cond_wait(), pthread_join(), pthread_testcancel, read(), sem_wait(), sigwaitinfo(), sigsuspend(), sigtimedwait(), sigwait(), sleep(), system(), tcdrain(), wait(), waitpid(), write(). * fcntl() when cmd is F_SETLKW Cancellation points may also occur while a thread is executing the following functions: closedir(), ctermid(), fclose(), fcntl()*, fflush(), fgetc(), fgets(), fopen(), fprintf(), fputc(), fputs(), fread(), freopen(), fscanf(), fseek(), ftell(), fwrite(), getc(), getc_unlocked(), getchar(), getchar_unlocked(), getcwd(), getgrgid(), getgrgid_r(), getgrnam(), getgrnam_r(), getlogin(), getlogin_r(), getpwnam(), getpwnam_r(), getpwuid(), getpwuid_r(), gets(), lseek(), opendir(), perror(), printf(), putc(), putc_unlocked(), putchar(), putchar_unlocked(), puts(), readdir(), remove(), rename(), rewind(), rewinddir(), scanf(), tmpfile() tmpname(), ttyname(), ttyname_r(), ungetc(), unlink(). * fcntl() for any value of the command argument I've got some other changes waiting for JB to review. If you proceed with this, I'd like to review whatever you come up with. Dan Eischen [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Apple's planned appoach to permissions on movable filesystems
Pat Dirks wrote: ADOPTING "FOREIGN" FILESYSTEMS When a new, never before seen disk is first mounted in the system it's treated as "foreign". This can be changed (with "root" permissions) to make the filesystem "local". The filesystem's ID is added to the list of local filesystems and forever after when the disk is mounted it's treated as "local". As part of this "adoption" process the users is prompted to choose one of two ways to handle the existing permissions on the disk: * Retain them as-is (useful for cases where you have external reasons to believe the numeric user and group IDs on the filesystem are sensible and meaningful) OR * Overwrite all owner/group information with the reserved ID "unknown". This leaves the effective permissions unchanged but enables them to be changed individually. You can chown(2) and chgrp(2) files and directories. Note that one interesting option might be to provide a one-time-only "adoption" which has no permanent effect; when the disk is encountered later it is once again "foreign". This might make sense for security reasons (if you don't want this disk to become a possible future carrier for SetUID binaries) I see a problem with the above. Suppose I receive a disk from a friend, and then adopt it. I change owners and groups throughout the fs (chown -R usr:grp is your friend :), and work on it for a while. Later, _I return the disk to the original owner_. Now, the disk will be recognized in _his_ computer as being local, when, in fact, it should be treated as foreign. For this reason, I suggest you scrap the fs id if, when making it local, you opt to replace owners and groups. A problem might still exist where you have a superset of the owners and groups of whoever lent you the disk. In this case, you might end up adding owners and groups that do not exist in the system where the disk came from (and will be returned to). I think this is a lesser problem, though. It is no worse than uid/gid problems with NFS. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] "I always feel generous when I'm in the inner circle of a conspiracy to subvert the world order and, with a small group of allies, just defeated an alien invasion. Maybe I should value myself a little more?" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Voice modems
Does anyone have any experience with controlling voice modems from FreeBSD, doing stuff like DTMF-driven phone reservation etc? DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Real Port Combo cardbus or legacy?
Do any of the RealPort 10/100+ 56kModem cards work with FreeBSD 3.3-RELEASE using PAO3-19991005.tar.gz? I tried a frends card with no luck.. I tried using ftp://dogma.freebsd-uk.eu.org/pub/scott/xe_drv/xe_drv-1.20.tar.gz but the files in /usr/src/sys/dev/pccard seemed to be newer and referance a differant location. I tried configurations 0x27 0xf 0x1f 0x17 and 0x3f. 0x3f and 0x1f brought up the xe0 device with errors. I dont have the card any more so i cant post more robust errors other than what I have left over in /var/log/messages.. Oct 5 15:16:03 ricoh /kernel: card1: assign xe0 iobase 0x2e8 irq 9 Oct 5 15:16:04 ricoh /kernel: xe: Probing for unit 0 Oct 5 15:16:04 ricoh /kernel: xe0: attach Oct 5 15:16:04 ricoh /kernel: Oct 5 15:16:04 ricoh /kernel: xe0: Xircom CEM56, bonding version 0x55, 100Mbps capable, with modem Oct 5 15:16:04 ricoh /kernel: xe0: DingoID = 0x444b, RevisionID = 0x1, VendorID = 0 Oct 5 15:16:04 ricoh /kernel: xe0: Ethernet address 00:10:a4:fb:0d:0f Oct 5 15:16:04 ricoh /kernel: xe0: hard_reset Oct 5 15:16:04 ricoh /kernel: xe0: setmedia Oct 5 15:16:04 ricoh /kernel: xe0: disable_intr Oct 5 15:16:04 ricoh /kernel: xe0: init Oct 5 15:16:06 ricoh /kernel: xe0: setmedia Oct 5 15:16:06 ricoh /kernel: xe0: disable_intr Oct 5 15:16:06 ricoh /kernel: xe0: soft_reset Oct 5 15:16:06 ricoh /kernel: xe0: silicon revision = 5 Oct 5 15:16:06 ricoh /kernel: xe0: disable_intr Oct 5 15:16:06 ricoh /kernel: xe0: MII registers: 0:3400 1:7809 4:01e1 5: 6: Thanks in advance Richard Puga [EMAIL PROTECTED] PS my laptop supports legacy and CardBuss (card I borrowed was legacy) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: New command for cdcontrol(1)
On 06-Oct-99 Josef Karthauser wrote: On Wed, Oct 06, 1999 at 01:02:14PM +0300, Sergey Shkonda wrote: I'm using this patch for cdcontrol(1): cdidPrint the xmcd's CD id. Is the method used by xmcd used by anything else or is it just _a_ method. What's the algorithm that the cddb boys use? If it's the same then I believe that this is a useful patch. If it's different - it should be made same :) The method used by xmcd is a specific method specified by cddb, and the comments in the patch he posted look just like the source code that holds the authoritative algorithm for getting this id, so I believe it is the proper algorithm. I also think it is a useful patch, btw. Joe --- John Baldwin [EMAIL PROTECTED] -- http://www.cslab.vt.edu/~jobaldwi/ PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Apple's planned appoach to permissions on movable filesystems
At 4:20 AM -0700 10/6/99, Daniel C. Sobral wrote: It is no worse than uid/gid problems with NFS. Umm, what is this, FreeBSD-Humor? Thanks for the laugh, and remember, it's just a nasty old rumor that NFS stands for "No File Security" :-/ -- Conrad Minshall ... [EMAIL PROTECTED] ... 408 974-2749 Apple Computer ... Mac OS X Core Operating Systems ... NFS/UDF/etc Alternative email address: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Voice modems
On Wed, Oct 06, 1999 at 02:26:26PM +0200, Dag-Erling Smorgrav wrote: Does anyone have any experience with controlling voice modems from FreeBSD, doing stuff like DTMF-driven phone reservation etc? Have a look at mgetty in the portscollection. Here it works great with an old Zyxel 1696 CU matthias -- \\ // N N EEE TTT Matthias Meyser, [EMAIL PROTECTED] \\ // eee NN N ET Gesellschaft fuer Informations- und \X/ e e N N N EE T Kommunikationssysteme mbH // \\ e ee N NN ET 38678 Clausthal-Zellerfeld, Burgstaetter Strasse 6 // \\ N N EEE T Telefon: +49-5323-94018 Fax: +49-5323-94011 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Developer assessment (was Re: A bike shed ...)
On Oct 4, 12:52am, Darryl Okahata wrote: } Subject: Re: Developer assessment (was Re: A bike shed ...) } 1. Instant escalation. Example: supplicant A asks question in FreeBSD }group. Some FreeBSD contributor says, "RTFM", and does not give any }useful information whatsoever like which "FM" or even a vague area. }Supplicant A asks for more information, said FreeBSD contributor }insults supplicant A for being clueless newbie crud and flamefest }results. } }Lesson: if you can't say anything nice, don't say it at all. Look at }it this way: you won't have wasted your time, your blood pressure }will be lower, and you won't look stupid for having stooped to }insults, which also doesn't reflect well upon the FreeBSD }contributors. This is reasonable advice, though what sometimes happens is that A is then frustrated by the deafening silence and either spams multiple lists or becomes irate because he thinks he is being actively shunned. This can also be a problem if the question isn't answered in the FM and the few FreeBSD experts who are competent to answer the question are too busy to answer right away or are otherwise distracted. I think it would lower the frustration level all around if we had some volunteer question answerers to take some of the load off the developers. It doesn't sound like fun to me, but neither does doing documentation, but somehow FreeBSD has managed to find volunteers who only work on the documentation. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: New command for cdcontrol(1)
On Wed, Oct 06, 1999 at 03:39:41PM +0300, Sergey Shkonda wrote: Yes, this algorithm used in cddb. Does the method have a specific name? What I'm getting at is the manual page entry: cdidPrint the xmcd's CD id. Should be something like: cdidDisplay the serial number of the cd using the method used by the cddb (URL) project. Joe -- Josef KarthauserFreeBSD: How many times have you booted today? Technical Manager Viagra for your server (http://www.uk.freebsd.org) Pavilion Internet plc. [[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: New command for cdcontrol(1)
On Wed, 6 Oct 1999 13:05:08 +0100, Josef Karthauser wrote: On Wed, Oct 06, 1999 at 01:02:14PM +0300, Sergey Shkonda wrote: I'm using this patch for cdcontrol(1): cdidPrint the xmcd's CD id. Is the method used by xmcd used by anything else or is it just _a_ method. What's the algorithm that the cddb boys use? If it's the same then I believe that this is a useful patch. If it's different - it should be made same :) Yes, this algorithm used in cddb. -- Sergey Shkonda [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: New command for cdcontrol(1)
On Wed, 6 Oct 1999 14:05:29 +0100, Josef Karthauser wrote: On Wed, Oct 06, 1999 at 03:39:41PM +0300, Sergey Shkonda wrote: Yes, this algorithm used in cddb. Does the method have a specific name? What I'm getting at is the manual page entry: I don't know any name for this method. From cddbd README file: :The CD Database Server (cddbd) is a program designed to allow remote access :of xmcd-style Compact Disc database entries via the Internet. Xmcd is an :X11/Motif-based CD player utility written by Ti Kan, which, as of version :2.0 supports remote access of CDDB protocol servers. This server also cdidPrint the xmcd's CD id. Should be something like: cdidDisplay the serial number of the cd using the method used by the cddb (URL) project. I think it's better description. -- Sergey Shkonda [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Stupid Newbie questions (was re: developer assessment)
[EMAIL PROTECTED] writes: http://www.blackhelicopters.org/~dispatch/stupid-bsd-questions.txt Looks great! BTW, do the hot twins down the hall have a phone number? 8) DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: bind(2) sets errno to undocumented EAGAIN?
Charles Randall [EMAIL PROTECTED] writes: Under what conditions does bind(2) set errno to EAGAIN? Either all ports being used up or malloc fails in the kernel. /assar To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Stupid Newbie questions (was re: developer assessment)
[EMAIL PROTECTED] writes: http://www.blackhelicopters.org/~dispatch/stupid-bsd-questions.txt Looks great! Thanks. I've moved it to a have a slightly less offensive URL, and will be updating this as more arguments ensue. http://www.blackhelicopters.org/~dispatch/bsd-self-help.html Thanks to Wes Peters for the html; I was so annoyed at the flamewar that I didn't bother taking care of that before putting it up. ;) I'll be fixing it up further. Feel free to send newbies here, rather than flaming them. For those who haven't read it, this is a "what Mr. Newbie should do before mailing freebsd-*, how to do those things, and what level of roasting he can expect if he doesn't do them first, and why." BTW, do the hot twins down the hall have a phone number? 8) They do. But if I gave it to an active committer you'd stop working on FreeBSD, at least until they were done with you. And we can't have that. ;) ==ml To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Apple's planned appoach to permissions on movable filesystems
Conrad Minshall wrote: At 4:20 AM -0700 10/6/99, Daniel C. Sobral wrote: It is no worse than uid/gid problems with NFS. Umm, what is this, FreeBSD-Humor? Thanks for the laugh, and remember, it's just a nasty old rumor that NFS stands for "No File Security" :-/ This is no joke. When you make a fs "directly" available, there is only one way of providing security: encryption. Otherwise, I have to rely on ensuring the safety of the media, which can be a very difficult proposition. One would better assume that files available over NFS will be read by anyone who wants, and, likewise, that files available on removable media will be read by anyone who wants. That side of the problem does not belong to this discussion. The question here is how to minimize the cost/benefit ratio of letting users mount external file systems on their own. At the very least, the system must never trust that data. Ergo, no suid/sgid. If you rely on users not having any binaries they want on the system as a form of security, and even _think_ of providing user-mountable external media, I must laugh on your face. Thus, it's not so much of a problem of security of the system, beyond the system not trusting a single nibble of that data (and that *includes* not crashing if that fs is inconsistent), but a problem security and convenience for _that_ user. In this light, mixed uid/gid is just an inconvenience (though it can be a hell of an inconvenience). -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] "I always feel generous when I'm in the inner circle of a conspiracy to subvert the world order and, with a small group of allies, just defeated an alien invasion. Maybe I should value myself a little more?" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Stupid Newbie questions (was re: developer assessment)
Dag-Erling Smorgrav wrote: [EMAIL PROTECTED] writes: http://www.blackhelicopters.org/~dispatch/stupid-bsd-questions.txt Looks great! BTW, do the hot twins down the hall have a phone number? 8) I think it was more on the lines of "Suppose a FreeBSD developer had a date with a couple of hot twins..." :-) -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] "I always feel generous when I'm in the inner circle of a conspiracy to subvert the world order and, with a small group of allies, just defeated an alien invasion. Maybe I should value myself a little more?" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Apple's planned appoach to permissions on movable filesystems
On Tue, 5 Oct 1999, Pat Dirks wrote: Hi, I'm the File Systems Tech Lead at Apple in the Mac OS X Core OS group. We've been struggling with the question of how best to handle permissions on disks that are moved between systems for Mac OS X and Mac OS X Server: the problem is that numeric IDs in inodes (or their moral equivalent) written on the filesystem on one system don't necessarily map to the same user, if they're valid at all, on another system (although they MIGHT). With ZIP drives holding appreciable volumes of data and multi-gigabyte FireWire drives becoming more common this is an issue that will definitely pop up more and more as people carry data with them on removable disk filesystems. [snip] Have you given consideration to systems where the user/group database is kept for (possibly a large) number of computers in a centralised manner by say hesiod or nys (nis+). It would be nice if there was an easy interface with these so that distributing the local system id numbers need not be done by hand. -Patrick. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Making a few links after 4.0-CURRENT installation ??
Hi there Marcel. I have build a 4.0-CURRENT snapshot release. After installation some of the applications can't get some of the libraries, for example [ libc.so.3 ] This is not a problem, just need to do a [ ln -s libc.so.4 libc.so.3 ] and another one [ ln -s libncurses.so.2 libtermcap.so.2 ] under the directory [ /usr/lib ]. These are not the same files as for example /usr/lib/compat/aout/libtermcap.so.2.1. The reason for this is probably the bumping of the version numbers with the new commits. Are somebody going to add some links in compat3X ( so that the links is automatically created by installation ) or are all the packages going to be recompiled to use the new version numbers ( including X ) There are just a few links wich should be made, should'nt take to much time to add the creation of a few links to compat3x ? begin:vcard n:Kruger;Johan tel;cell:+27 83 3015923 tel;fax:+27 12 6651343 tel;home:+27 83 3015923 tel;work:+27 12 6651338 x-mozilla-html:FALSE org:Nanoteq;Development version:2.1 email;internet:[EMAIL PROTECTED] title:Mr adr;quoted-printable:;;P.O BOX 12872=0D=0AOnderstepoort=0D=0A0110=0D=0ASouth Africa;Pretoria;Gauteng;0110;South Africa x-mozilla-cpt:;0 fn:Johan Kruger end:vcard
Re: Apple's planned appoach to permissions on movable filesystems
On 5 Oct, Pat Dirks wrote: Sorry if I'm talking nonsense or if somebody else already pointed this out, i usually just lurk around this list, but if I'm right I think it is of sufficient significance... ADOPTING "FOREIGN" FILESYSTEMS When a new, never before seen disk is first mounted in the system it's treated as "foreign". This can be changed (with "root" permissions) to make the filesystem "local". The filesystem's ID is added to the list of local filesystems and forever after when the disk is mounted it's treated as "local". As part of this "adoption" process the users is prompted to choose one of two ways to handle the existing permissions on the disk: Adding the filesystem to the systems list of local filesystems is not going to guarantee that the filesystem is local at all. If you move a disk from machine A to machine B, both machines will know the disk with that ID to be local. Moving the disk back to machine A will cause it to accept a filesystem as "local" that is actually "foreign". The "solution" would be to remove it's ID from the list when the filesystem is removed from the system, but AFAIK the only way to detect that is the "umount" that is required to do such. However, an umount is not enough reason to unmark a filesystem as "local"; it also happens at reboot, to name just one of the many occurances of umount. As may become obvious, I'm not an expert at this at all. I would rather brand the filesystem with the ID of the host. The starting situation is an "unmarked" filesystem. If a host detects the mounting of an "unmarked" filesystem, it will brand it with it's ID. If it detects a filesystem that has an ID that differs from the host's ID, it is a foreign filesystem. Seems quite simple to me... -- Alban Hertroys. http://wit401310.student.utwente.nl --- If I had a sig it would be fun. The quest for the Holy Sig has begun. I have not yet a clue, What will you see next issue? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ARPs on a bridge
I still don't fully understand where, in the picture below, is the "system" which you want to modify and what is instead standard stuff that you cannot touch... From your description this is what i understand: customer [ DSL bridge ]--+[ main router ]-- rest of net. | customer [ DSL bridge ]--+ | repeat 150 to 900 times | shared frame relay without | multicast/broadcast support customer [ DSL bridge ]--+ each DLCI is modeled as a PTP connection, so the system sees a physical interface for each channel. The bridge software just sees then as bridged interfaces. the "right" way to do it is to allocate a subnet to each bridge group, as different bridge groups cant talk at the mac layer by design. Im just trying to come up with an easy solution to free up addtional IP space so customers with only 2 address dont have to get a whole subnet. cheers luigi ---+- Luigi RIZZO, [EMAIL PROTECTED] . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) http://www.iet.unipi.it/~luigi/ngc99/ First International Workshop on Networked Group Communication ---+- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: New command for cdcontrol(1)
On Wed, Oct 06, 1999 at 04:25:09PM +0300, Sergey Shkonda wrote: cdidDisplay the serial number of the cd using the method used by the cddb (URL) project. I think it's better description. If it wasn't clear: cdidDisplay the serial number of the cd using the method used by the cddb (http://www.cddb.org) project. Joe -- Josef KarthauserFreeBSD: How many times have you booted today? Technical Manager Viagra for your server (http://www.uk.freebsd.org) Pavilion Internet plc. [[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: bind(2) sets errno to undocumented EAGAIN?
Charles Randall writes: Under what conditions does bind(2) set errno to EAGAIN? The 3.2R bind(2) manual page does not list that as a valid value for errno when bind returns -1. Please file a PR so this gets fixed. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Making a few links after 4.0-CURRENT installation ??
Johan Kruger wrote: After installation some of the applications can't get some of the libraries, for example [ libc.so.3 ] This is not a problem, just need to do a [ ln -s libc.so.4 libc.so.3 ] and another one [ ln -s libncurses.so.2 libtermcap.so.2 ] under the directory [ /usr/lib ]. You can't just make a link for libc. They are different. The reason for this is probably the bumping of the version numbers with the new commits. Yep. Are somebody going to add some links in compat3X ( so that the links is automatically created by installation ) or are all the packages going to be recompiled to use the new version numbers ( including X ) The libraries should probably be added to compat3x, yes. -- Marcel Moolenaarmailto:[EMAIL PROTECTED] SCC Internetworking Databases http://www.scc.nl/ The FreeBSD projectmailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ARPs on a bridge
At 09:56 AM 10/6/99 +0100, Luigi Rizzo wrote: Is there a way to force a Freebsd system to route to the same logican IP network rather than send a redirect? The situation occurs with segmented bridges where customers on the same logical IP network are on separate bridge groups. When trying to reach one another, they are getting redirects however they are not permitted to arp across groups. ... (long explaination moved to the end)... I think i don't understand the architecture of the system, so could you explain a bit more about that -- i would like to learn more about this. How many physical and logical interfaces does the FreeBSD system see ? From your description this is what i understand: customer [ DSL bridge ]--+[ main router ]-- rest of net. | customer [ DSL bridge ]--+ | repeat 150 to 900 times | shared frame relay without | multicast/broadcast support customer [ DSL bridge ]--+ each DLCI is modeled as a PTP connection, so the system sees a physical interface for each channel. The bridge software just sees then as bridged interfaces. the "right" way to do it is to allocate a subnet to each bridge group, as different bridge groups cant talk at the mac layer by design. Im just trying to come up with an easy solution to free up addtional IP space so customers with only 2 address dont have to get a whole subnet. dennis and the understanding is that the 'DSL bridge' is perhaps implemented with a FreeBSD-based box with an ethernet on the customer side and a suitable card on the other side. Now if the DSL bridge is "almost" a bridge (in the sense that it filters broadcast traffic) then your architecture "almost" works (except when operation depends on traffic that you filter) and you need a separate mechanism to implement the functionality killed by the filtering. E.g. recognize that some broadcasts (e.g. ARP) are special and need to be forwarded anyways... cheers luigi On a DSL bridge you have 150 to 900 customers bridged on a relatively low bandwidth line (frame relay in this case). Forwarding broadcast traffic is very undesireable as you have to replicate the packet 900 times, and since you know the IP assignement for the DLCI you dont need to forward it to everyone. Each customer is on a different bridge group so traffic cannot be bridged between them, so you have to route, but you dont want to have to allocate a subnet to each bridge group either. The problem is that, from the FreeBSD boxes view, you are routing to the same logical net (assuming that all of the bridge groups are in the same IP space. We're not talking about bridging a couple of ethernets here. Dennis To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Netscape Bus Error
Hi, On Tue, 5 Oct 1999, David G Andersen wrote: It most likely is. I've found a pretty reliable way to crash Netscape 4.6 and 4.7-freebsd (either us or export): Open two windows, and visit slashdot in both of them. Actually try submitting a story in just one window - I've had it crash about 2/3 of the time lately. I finally gave in and used lynx to submit the story. Brett * Dr. Brett Taylor [EMAIL PROTECTED]* Dept of Chem and Physics* Curie 39A (540) 831-6147 * Dept. of Mathematics and Statistics * Walker 234 (540) 831-5410 * * To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Apple's planned appoach to permissions on movable filesystems
On Wed, 6 Oct 1999, Darren R. Davis wrote: Narvi wrote: [snip] Have you given consideration to systems where the user/group database is kept for (possibly a large) number of computers in a centralised manner by say hesiod or nys (nis+). It would be nice if there was an easy interface with these so that distributing the local system id numbers need not be done by hand. If I was going to look into that kind of approach I would seriously look into some sort of Directory Server tie in through LDAP. Darren Only people at *MANY* sites are already using NIS and Hesiod (or some entirely different way ) and are very unlikely to migrate to LDAP or some other directory or not directory scheme for it, or probably even adapt it. No matter *what* scheme they are already using, they will expect the interface to the system ids to be able to use it. Mandating scheme XYZ is just like saying "Here, this is how we want you to distribute passwords. Forget about Kerberos and NIS+ or whatever other scheme you may have in place." Which is why I only talked about the interface, not what might be behind it or connected to it. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Apple's planned appoach to permissions on movable filesystems
On Wed, Oct 06, 1999 at 11:18:59PM +0900, Daniel C. Sobral wrote: One would better assume that files available over NFS will be read by anyone who wants, and, likewise, that files available on removable media will be read by anyone who wants. That side of the problem does not belong to this discussion. [...] The question here is how to minimize the cost/benefit ratio of letting users mount external file systems on their own. At the very least, the system must never trust that data. Ergo, no suid/sgid. Show me a disk that's _not_ removable. By your logic we would have _no_ sguid/sgid binaries _ever._ Physical access to a machine is always a security risk. Why would you treat easily-removable media any differently to slightly-harder-to-remove media? You still need to break into the vault to remove them. Joe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Release build
Does anybody know why ( i know that the directory /R/stage/trees/krb/ does not exist , but the directory /R/stage/trees/krb4/ do exist ) ?? For some reason, your src/release/* area is not getting updated. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Apple's planned appoach to permissions on movable filesystems
Alban Hertroys wrote: On 5 Oct, Pat Dirks wrote: Sorry if I'm talking nonsense or if somebody else already pointed this out, i usually just lurk around this list, but if I'm right I think it is of sufficient significance... ADOPTING "FOREIGN" FILESYSTEMS When a new, never before seen disk is first mounted in the system it's treated as "foreign". This can be changed (with "root" permissions) to make the filesystem "local". The filesystem's ID is added to the list of local filesystems and forever after when the disk is mounted it's treated as "local". As part of this "adoption" process the users is prompted to choose one of two ways to handle the existing permissions on the disk: Adding the filesystem to the systems list of local filesystems is not going to guarantee that the filesystem is local at all. If you move a disk from machine A to machine B, both machines will know the disk with that ID to be local. Moving the disk back to machine A will cause it to accept a filesystem as "local" that is actually "foreign". The "solution" would be to remove it's ID from the list when the filesystem is removed from the system, but AFAIK the only way to detect that is the "umount" that is required to do such. However, an umount is not enough reason to unmark a filesystem as "local"; it also happens at reboot, to name just one of the many occurances of umount. As may become obvious, I'm not an expert at this at all. I would rather brand the filesystem with the ID of the host. The starting situation is an "unmarked" filesystem. If a host detects the mounting of an "unmarked" filesystem, it will brand it with it's ID. If it detects a filesystem that has an ID that differs from the host's ID, it is a foreign filesystem. Seems quite simple to me... -- Alban Hertroys. http://wit401310.student.utwente.nl --- If I had a sig it would be fun. The quest for the Holy Sig has begun. I have not yet a clue, What will you see next issue? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message Having some experience with the way Iomega handled this, they did this very thing. They generated an ID for the disk. They also would have it be changed every time it was mounted. That way if the ID didn't change from what was expected it was assumed to have not changed. If it ever moved to another system, it was rebranded and was now viewed as changed. Darren begin:vcard n:Davis;Darren tel;fax:801.765.1313 tel;work:801.765.4999 x-mozilla-html:TRUE url:http://www.calderasystems.com org:Caldera Systems, Inc.;Engineering adr:;;240 West Center Street;Orem;UT;84057;USA version:2.1 email;internet:[EMAIL PROTECTED] title:Director of Research x-mozilla-cpt:;-5088 fn:Darren Davis end:vcard
Re: Stupid Newbie questions (was re: developer assessment)
Today Michael Lucas wrote: BTW, do the hot twins down the hall have a phone number? 8) They do. But if I gave it to an active committer you'd stop working on FreeBSD, at least until they were done with you. And we can't have that. ;) Think carrot/stick, Michael. "DES, I'd really like to see `insert your desired feature here' in FreeBSD." Bet you could get it. :) -- Jack O'NeillSystems Administrator / Systems Analyst [EMAIL PROTECTED] Crystal Wind Communications, Inc. Finger [EMAIL PROTECTED] for my PGP key. PGP Key fingerprint = F6 C4 E6 D4 2F 15 A7 67 FD 09 E9 3C 5F CC EB CD enriched, vcard, HTML messages /dev/null -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Apple's planned appoach to permissions on movable filesystems
:Show me a disk that's _not_ removable. By your logic we would have _no_ :sguid/sgid binaries _ever._ : :Physical access to a machine is always a security risk. Why would you :treat easily-removable media any differently to slightly-harder-to-remove :media? You still need to break into the vault to remove them. : :Joe Well, I don't think this is a very fair argument. There are plenty of situations where you might want to differentiate, even with physical access. For example, take PC's in a library. Lets say that the PC's get all their critical stuff via read-only NFS mounts, but the library wants to allow people to import and export files via the floppy drive. In this example, there is a very definite distinction between a filesystem on the floppy drive and 'everything else'. Even when you throw a hard drive in, just because someone has physical access to the outside of the machine does not necessarily mean that he has physical access to the inside of the machine. Take, for example, a supervised machine or machine which is 'locked down' and has a bios password installed. While it is certainly true that a person could eventually get physical access into the machine, it is a significantly more difficult task and therefore a significant distinction still exists between the data stored on the hard drive and stored in, say, a floppy. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Apple's planned appoach to permissions on movable filesystems
Narvi wrote: On Tue, 5 Oct 1999, Pat Dirks wrote: Hi, I'm the File Systems Tech Lead at Apple in the Mac OS X Core OS group. We've been struggling with the question of how best to handle permissions on disks that are moved between systems for Mac OS X and Mac OS X Server: the problem is that numeric IDs in inodes (or their moral equivalent) written on the filesystem on one system don't necessarily map to the same user, if they're valid at all, on another system (although they MIGHT). With ZIP drives holding appreciable volumes of data and multi-gigabyte FireWire drives becoming more common this is an issue that will definitely pop up more and more as people carry data with them on removable disk filesystems. [snip] Have you given consideration to systems where the user/group database is kept for (possibly a large) number of computers in a centralised manner by say hesiod or nys (nis+). It would be nice if there was an easy interface with these so that distributing the local system id numbers need not be done by hand. -Patrick. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message If I was going to look into that kind of approach I would seriously look into some sort of Directory Server tie in through LDAP. Darren begin:vcard n:Davis;Darren tel;fax:801.765.1313 tel;work:801.765.4999 x-mozilla-html:TRUE url:http://www.calderasystems.com org:Caldera Systems, Inc.;Engineering adr:;;240 West Center Street;Orem;UT;84057;USA version:2.1 email;internet:[EMAIL PROTECTED] title:Director of Research x-mozilla-cpt:;-5088 fn:Darren Davis end:vcard
Re: Apple's planned appoach to permissions on movable filesystems
Joe Abley wrote: On Wed, Oct 06, 1999 at 11:18:59PM +0900, Daniel C. Sobral wrote: One would better assume that files available over NFS will be read by anyone who wants, and, likewise, that files available on removable media will be read by anyone who wants. That side of the problem does not belong to this discussion. [...] The question here is how to minimize the cost/benefit ratio of letting users mount external file systems on their own. At the very least, the system must never trust that data. Ergo, no suid/sgid. Show me a disk that's _not_ removable. By your logic we would have _no_ sguid/sgid binaries _ever._ Please, don't give me this crap. "Removable media" is a very well-defined terminology. Physical access to a machine is always a security risk. Why would you treat easily-removable media any differently to slightly-harder-to-remove media? You still need to break into the vault to remove them. Why? Because in latter case you do not expect users to remove (or insert, which is that case above) media in the system, except as a serious breach in physical security, and in the former case you *EXPECT* and *PROVIDE THE MEANS FOR* the user change the media. That makes all the difference. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] "I always feel generous when I'm in the inner circle of a conspiracy to subvert the world order and, with a small group of allies, just defeated an alien invasion. Maybe I should value myself a little more?" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Non-standard FFS parameters
On Tue, 5 Oct 1999, Matthew Dillon wrote: Mmmm. I ran into problems in -current trying to use a block size of 64K. It should be relatively easy for me to track this down and fix it, but I don't know if there are other problems lying in wait. IOW it may appear to run while eating your FS away No,thanks :-/ :* what maximum value can I use for -i (bytes per inode) parmeter? I :aalready tried 16mln ... I wouldn't go that high. Try 262144. Here's an example: Why? I only need a couple o hundred inodes on this fs.. newfs -i 262144 -b 65536 -f 8192 /dev/rvn1c test3:/root# newfs -i 262144 -f 8192 -b 65536 /dev/rvn1c /dev/rvn1c: 83886080 sectors in 2560 cylinders of 1 tracks, 32768 sectors 40960.0MB in 160 cyl groups (16 c/g, 256.00MB/g, 1024 i/g) Well, yes, but you used non-standar blocksize which you yourself don't recommend. With standard 8192/1024 this command creates millions of inodes which I don't need - what's worse, they cause fsck to run for hours instead of seconds. :* and finally, how th above choices affect the FS performance in my case? : :Thanks in advance for any insights! : :Andrzej Bialecki The higher the bytes per inode the fewer the inodes and the faster fsck will run if you have to recover the filesystem. Too high a bytes-per-inode will screw up the filesystem's ability to manage the cylinder groups, though. Why? I thought this parameter describes (indirectly) only the total number of inodes in the FS, which is otherwise set proportionally to FS size, assuming it will be filled with very small files (2048B IIRC). I suspect it might have something to do with the placement policy (which CG to use to put additional blocks belonging to the file), but I don't see any immediate connection... The higher the block size the fewer indirect blocks are required to access a linear file, but as the block size increases the system's caching effectiveness will decrease. I would not use a block size greater then 64K, and I wouldn't specify a bytes-per-inode greater then 262144. There may be problems specifying larger block sizes, though nothing that we can't fix. What kind of problems? Will it simply not work, or will it corrupt the FS? Thanks a lot for these comments! Andrzej Bialecki // [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com) // --- // -- FreeBSD: The Power to Serve. http://www.freebsd.org // --- Small Embedded FreeBSD: http://www.freebsd.org/~picobsd/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Apple's planned appoach to permissions on movable filesystems
[.] Instead we decided to leave all name - ID mapping systems unchanged and rely on a distinction between "local" filesystems whose permissions information should be used and a "foreign" filesystem mode where owner and group IDs are ignored. [.] I think the owner and group of the person that mounted the filesystem should be assigned to all files on that filesystem in FOREIGN mode. -u and -g switches should be permitted to modify these, the -u being restricted to root and the -g restricted to root or one of the groups to which you are a member. This assumes the BSD style I-must-have-permission-to-read-and-write- the-raw-partitiion style filesystem mounting by users. It would have horrendous implications with the linux-style fstab-says-anyone-can- mount-this idea. But then, you already mention this later on :-] The filesystem code would also mask all suid bits and ignore all char/device files on FOREIGN media (as you've already said too). [.] media) so we settled on identifying filesystems instead. I don't think it's a good idea to be able to identify the filesystem as being your own. It's too easy to introduce security problems that way. I'd suggest a default of FOREIGN and a root-only mount option for LOCAL - ie, root decides, nothing's automated. [.] As long as the filesystem is "foreign" no owner or group changes (chown(2), chgrp(2)) are allowed (the id spaces are very possibly mutually meaningless; local name - id mappings could make no sense to the original owner's system). chmod(2) should still work, though. And what uid/gid do new files get I can't say I like the idea of a magic ``nobody'' uid/gid. [.] -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.Awfulhak.org [EMAIL PROTECTED] Don't _EVER_ lose your sense of humour ! [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Apple's planned appoach to permissions on movable filesystems
| I think the owner and group of the person that mounted the filesystem | should be assigned to all files on that filesystem in FOREIGN mode. | -u and -g switches should be permitted to modify these, the -u being | restricted to root and the -g restricted to root or one of the groups | to which you are a member. And when you log out, and that disk is there when the next guy logs in, what happens? What if the media is inserted when nobody is logged in? Ignore it? Mount it as the next guy who logs in? There are pitfalls all around. | I don't think it's a good idea to be able to identify the filesystem | as being your own. It's too easy to introduce security problems that | way. I'd suggest a default of FOREIGN and a root-only mount option | for LOCAL - ie, root decides, nothing's automated. We it's too easy if we can't figure out a safe way to do this, yes. I think we can, though. Nothing automated... You will not enjoy Macintosh. :-) From the Core OS perspective, we would like to facilitate automation by the higher level tools like the Finder. We're in agreement that declaring a disk local is a priveledged operation. | And what uid/gid do new files get I can't say I like the idea of | a magic ``nobody'' uid/gid. "nobody" is used by NFS as has a different semantic. We'd need a different name. "unknown" is pretty clear, I think. -Fred -- Wilfredo Sanchez, [EMAIL PROTECTED] Apple Computer, Inc., Core Operating Systems / BSD Technical Lead, Darwin Project 1 Infinite Loop, 302-4K, Cupertino, CA 95014 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Apple's planned appoach to permissions on movable filesystems
ADOPTING "FOREIGN" FILESYSTEMS When a new, never before seen disk is first mounted in the system it's treated as "foreign". This can be changed (with "root" permissions) to make the filesystem "local". The filesystem's ID is added to the list of local filesystems and forever after when the disk is mounted it's treated as "local". As part of this "adoption" process the users is prompted to choose one of two ways to handle the existing permissions on the disk: * Retain them as-is (useful for cases where you have external reasons to believe the numeric user and group IDs on the filesystem are sensible and meaningful) OR * Overwrite all owner/group information with the reserved ID "unknown". This leaves the effective permissions unchanged but enables them to be changed individually. You can chown(2) and chgrp(2) files and directories. Note that one interesting option might be to provide a one-time-only "adoption" which has no permanent effect; when the disk is encountered later it is once again "foreign". This might make sense for security reasons (if you don't want this disk to become a possible future carrier for SetUID binaries) I see a problem with the above. Suppose I receive a disk from a friend, and then adopt it. I change owners and groups throughout the fs (chown -R usr:grp is your friend :), and work on it for a while. Later, _I return the disk to the original owner_. Now, the disk will be recognized in _his_ computer as being local, when, in fact, it should be treated as foreign. For this reason, I suggest you scrap the fs id if, when making it local, you opt to replace owners and groups. I'm sorry I didn't mention it in my original post but the plan is that whenever a filesystem is "adopted" and the permissions are overwritten the filesystem's ID is changed to prevent it being recognized as "local" to any systems that previously knew it. If the filesystem's "adopted" while retaining the privileges, the systems that recognize the filesystem as "local" must be able to make sense of the same set of IDs (because they're all from the same source, for instance) and it makes sense to leave the filesystem ID unchanged. It must be possible to have a disk that I can swap between two systems here on the floor when I know there are no conflicting name - ID mappings, in which case the two systems must know the filesystem in question by the same filesystem ID. A problem might still exist where you have a superset of the owners and groups of whoever lent you the disk. In this case, you might end up adding owners and groups that do not exist in the system where the disk came from (and will be returned to). I think this is a lesser problem, though. It is no worse than uid/gid problems with NFS. That is indeed a problem, and whoever's deciding how to "adopt" the filesystem had better know what they're getting themselves into. Thanks! -Patrick. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Apple's planned appoach to permissions on movable filesystems
On 5 Oct, Pat Dirks wrote: Sorry if I'm talking nonsense or if somebody else already pointed this out, i usually just lurk around this list, but if I'm right I think it is of sufficient significance... ADOPTING "FOREIGN" FILESYSTEMS When a new, never before seen disk is first mounted in the system it's treated as "foreign". This can be changed (with "root" permissions) to make the filesystem "local". The filesystem's ID is added to the list of local filesystems and forever after when the disk is mounted it's treated as "local". As part of this "adoption" process the users is prompted to choose one of two ways to handle the existing permissions on the disk: Adding the filesystem to the systems list of local filesystems is not going to guarantee that the filesystem is local at all. If you move a disk from machine A to machine B, both machines will know the disk with that ID to be local. Moving the disk back to machine A will cause it to accept a filesystem as "local" that is actually "foreign". That's not a bug, that's a feature :-) Seriously, if a filesystem, created on system A, is "adopted" on system B with the option of retaining the existing IDs because they make sense on system B, with or without further manipulation through umapfs, it strikes me as DESIRABLE that newly created files and directories, tagged with IDs on system B, should show up as-is back on system A. I neglected to spell out in my original post that "adopting" a filesystem with the option of overwriting all permissions also changes the filesystem's ID and will prevent it from being recognized as "local" back on system A. The "solution" would be to remove it's ID from the list when the filesystem is removed from the system, but AFAIK the only way to detect that is the "umount" that is required to do such. However, an umount is not enough reason to unmark a filesystem as "local"; it also happens at reboot, to name just one of the many occurances of umount. As may become obvious, I'm not an expert at this at all. Perhaps the default behavior should be to accept a filesystem as local once only, requiring a special option to elect to treat the filesystem as "local" whenever it appears. Permanently connected local hard disks should be permanently recognized as "local", of course. I would rather brand the filesystem with the ID of the host. The starting situation is an "unmarked" filesystem. If a host detects the mounting of an "unmarked" filesystem, it will brand it with it's ID. If it detects a filesystem that has an ID that differs from the host's ID, it is a foreign filesystem. Seems quite simple to me... The problem with that is that you cannot create filesystems that can be "local" on more than one system, even though there might be a large group of systems that share a common name - ID mapping (NetInfo, NIS, LDAP, Kerberos, whatever). It also makes it impossible to create read-only volumes that are "local" on any system other than the creating system. I'm missing the advantage here. If filesystems are created with a unique ID that's entered into the local system's list of "local" filesystems, wouldn't the basic behavior be the same? Systems that don't recognize a newly mounted filesystem's ID will still default to treating it as "foreign" automatically. What's gained by branding filesystems with the ID of a SINGLE "owning" system? Thanks, -Patrick. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
New crash, NFS/multiple frees related. (Was: zalloci/pv_entry problem)
Same machine crashed, this time at a different place. I'm starting
to wonder if there may be a hardware issue with this machine, but the
errors I'm seeing in the logs are similar enough to the show-stopping
errors I had when all the machines were running the same newer -current,
so maybe it's just bad luck. In any case, here is the latest data. Any
input would be appreciated. I can resend the pertinent details to anyone
who needs them.
Thanks,
Doug
Fatal trap 12: page fault while in kernel mode
mp_lock = 0005; cpuid = 0; lapic.id = 0100
fault virtual address = 0x4800c040
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc01e2c40
stack pointer = 0x10:0xdc838a40
frame pointer = 0x10:0xdc838a44
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 97652 (miva)
interrupt mask = net tty bio cam - SMP: XXX
kernel: type 12 trap, code=0
panic: free: multiple frees
mp_lock = 0001; cpuid = 0; lapic.id = 0100
Debugger("panic")
Stopped at Debugger+0x37: movl$0,in_Debugger
db trace
Debugger(c0216d32) at Debugger+0x37
panic(c02162ff,c20e2440,dcef4bc0,dc838c94,4800c040) at panic+0xa8
free(c20e2440,c023b580,dd1c6e40,dc838c70,c0154ee7) at free+0xd3
cache_zap(c20e2440) at cache_zap+0xb3
cache_purge(dd1c6e40,20,dd1e2c60,c1c7a040,dc838c94) at cache_purge+0x37
getnewvnode(2,c1d3ce00,c1c58d00,dc838cc8,20) at getnewvnode+0x27e
nfs_nget(c1d3ce00,c111d860,20,dc838d64,dc838e1c) at nfs_nget+0x107
nfs_create(dc838e1c,0,dc838f80,fffb,da07aec0) at nfs_create+0x1673
vn_open(dc838eec,20a,180,da07aec0,c0239d4c) at vn_open+0xfa
open(da07aec0,dc838f80,1,80d5d80,bfbfd5f0) at open+0xbb
syscall(2f,2f,2f,bfbfd5f0,80d5d80) at syscall+0x19e
Xint0x80_syscall() at Xint0x80_syscall+0x31
I actually had better luck with x/s than I did with x/l, so here goes:
db x/s 0xc02162ff
__set_sysuninit_set_sym_M_FREE_uninit_sys_uninit+0x7b: free: multiple
frees
0xc20e2440: @$\016\302\264Y\302\301@\026\372\301H\335"\302
db x/s 0xc023b580
M_CACHE:\340\265#\300\200'*
db x/s 0xdd1c6e40
0xdd1c6e40:
db x/l 0xdd1c6e40
0xdc838c70: \234\214\203\334\202\203\025\300@n\034\335
db x/s 0xc0154ee7
cache_purge+0x37: \203\304\004\203\273\210
0xc20e2440: @$\016\302\264Y\302\301@\026\372\301H\335"\302
db x/s 0xdcef4bc0
0xdcef4bc0:
db x/l 0xdcef4bc0
db x/s 0xdc838c94
0xdc838c94:
db x/l 0xdc838c94
0xdd1e2c60: \300\346\343\335`3\001\335
0xc1c7a040:
\3617\335\300\346\203\335@\233g\335`\014\237\335@+\361\334@k%\335@\242B\335\300V\303\334@[\322\334\2405\032\335\300\266\305\334
db x/s 0xc1d3ce00
0xc1d3ce00:
db x/l 0xc1d3ce00
db x/s 0xc1c58d00
0xc1c58d00: \300f\025\300\250f\025\300
\320\032\300\024\323\031\300h\327\031\300\370\327\031\300\300\272\027\300\250f\025\300xh\025\300\334\327\032\300\250\004\032\300\334\273\027\300\334\333\031\300\250f\025\300
\245\027\300\250f\025\300\364\274\027\300\260\327\032\300@\317\032\300\250f\025\300\3745\032\300\014g\032\300\204\362\031\300P\210\032\300\3105\032\300\024\320\032\300T\325\031\300\250f\025\300
h\025\300X\247\032\300\320\004\032\300\004Q\032\300\250X\032\300x\240\032\300\224\317\032\300\220q\032\300\250f\025\300\360\224\027\300H\227\027\300\250f\025\300
\330\032\300\240f\025\300\250f\025\300\250f\025\300\250f\025\300
0xdc838cc8: \200\344\032\301\364\215\203\334oL\032\300
On Tue, 5 Oct 1999, Doug wrote:
On Mon, 4 Oct 1999, Luoqi Chen wrote:
If you have a crash dump, could you look at the 4 longwords starting
at address 0xc02698c0? It seemed to be an accouting problem. Do you
by any chance use any kld module? zalloc() calls from within a module
do not lock the vm_zone data structure, which is fine for UP but
dangerous for SMP.
Well the same machine crashed in the same place, so I can look at
the current crash for you:
Fatal trap 12: page fault while in kernel mode
mp_lock = 0102; cpuid = 1; lapic.id =
fault virtual address = 0x800018
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc01d1107
stack pointer = 0x10:0xdc98fe28
frame pointer = 0x10:0xdc98fe34
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 41226 (httpd)
interrupt mask = net tty bio cam - SMP: XXX
kernel: type 12 trap, code=0
Stopped at zalloci+0x33: movl0(%edx),%eax
db trace
zalloci(c02698c0,dc98fe58,c01f24c3,da07e7a4,91bb000) at zalloci+0x33
get_pv_entry(da07e7a4,91bb000,ffc246ec,0,dc98fe90) at get_pv_entry+0x4a
pmap_insert_entry(da07e7a4,91bb000,c0572b60,8206000) at
pmap_insert_entry+0x1f
pmap_copy(da07e7a4,dc8eeb64,80c6000,1f85000,80c6000) at
Re: Apple's planned appoach to permissions on movable filesystems
On Thu, 7 Oct 1999, Alban Hertroys wrote: On 6 Oct, Wilfredo Sanchez wrote: | I would rather brand the filesystem with the ID of the host. The | starting situation is an "unmarked" filesystem. If a host detects the | mounting of an "unmarked" filesystem, it will brand it with it's ID. If | it detects a filesystem that has an ID that differs from the host's ID, | it is a foreign filesystem. Seems quite simple to me... But then you have to put that information on the disk, and you're back to trusting the disk. "Um, yeah, I'm local. Trust me." Hmmm... But you can also fake the filesystem ID to be one that was previously known by the system. Just make the filesystem local, put some horrible executables on it, and write back the original idea (if that's at all necessary, I'm still not sure it gets changed in between). The problem is that you write a "unique" ID on the disk. You can read the disk, so you can store that ID and write it back if you do want to harm somebody. Is public key encryption, or something like that, a solution? Or is this not necessary? you could hash the superblocks and private key encrypt the hash. it still doesn't guarantee that the data hasn't been replaced 'in place'. for that you'd have to has the entire disk My .001 cts. -- Alban Hertroys. http://wit401310.student.utwente.nl --- If I had a sig it would be fun. The quest for the Holy Sig has begun. I have not yet a clue, What will you see next issue? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
