Re: On pthreads [Was: Re: I was accepted to LokiHack '99 at Atlanta Linux Showcase]

[Jeroen Ruigrok/Asmodai]

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)

[Sergey Shkonda]

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 
 #include 
 #include 
+#include 
 
 #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, "  | 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 ?

[Johan Kruger]

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]

[Daniel Eischen]

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

[Daniel C. Sobral]

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

Re: New command for cdcontrol(1)

[Josef Karthauser]

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 :)

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

Voice modems

[Dag-Erling Smorgrav]

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?

[Richard Puga]

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)

[John Baldwin]

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

[Conrad Minshall]

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

[Matthias Meyser]

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 ...)

[Don Lewis]

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)

[Josef Karthauser]

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)

[Sergey Shkonda]

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)

[Sergey Shkonda]

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)

[Dag-Erling Smorgrav]

[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?

[Assar Westerlund]

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)

[Michael Lucas]

> [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

[Daniel C. Sobral]

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)

[Daniel C. Sobral]

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

[Narvi]

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 ??

[Johan Kruger]

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

[Alban Hertroys]

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

[Luigi Rizzo]

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)

[Josef Karthauser]

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?

[Archie Cobbs]

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 ??

[Marcel Moolenaar]

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

[Dennis]

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

[Brett Taylor]

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

[Narvi]

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

[Joe Abley]

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

[Mark Murray]

> 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

[Darren R. Davis]

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)

[jack]

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

[Matthew Dillon]

: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

[Darren R. Davis]

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

[Daniel C. Sobral]

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: Developer assessment (was Re: A bike shed ...)

[Matthew D. Fuller]

On Wed, Oct 06, 1999 at 06:03:27AM -0700, a little birdie told me
that Don Lewis remarked
> 
> 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.

Indeed.
Wait; I just had a brainstorm!
We could even make a mailing list for it, and call it something like
'freebsd-questions' to make it easy for people to find!




-- 
Matthew Fuller (MF4839) |[EMAIL PROTECTED]
Unix Systems Administrator  |[EMAIL PROTECTED]
Specializing in FreeBSD |http://www.over-yonder.net/
FutureSouth Communications  |ISPHelp ISP Consulting

"The only reason I'm burning my candle at both ends, is because I
  haven't figured out how to light the middle yet"


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Non-standard FFS parameters

[Andrzej Bialecki]

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

[Brian Somers]

[.]
> 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]>
     <[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

[Pat Dirks]

>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.
>
>I think your best bet to implement something like this is looking
>at what mount_msdosfs in FreeBSD does, and possibly using the umapfs
>(mount_umap) system for mapping ID's as it sounds pretty close to
>what you guys are looking for.
>
>Another interesting idea would be to a utility to 'brand' removable
>media, so that a umapfs mapfile can be written to the disk in more
>friendly manner.
>
>However, it seems that a lot of this is going towards automation at
>guessing what a user wants, rather than allowing him to customize
>what he wants.

The problem trying to use the umapfs to solve the problem are that

 (a) there may be no mapping for some or all of the IDs involved
 (b) it presumes maintaining a mapping file ready-to-go when the disk 
is
 unmounted/removed
 (c) the real correspondence between users on the two systems is 
really
 external knowledge.  Even if I could map "Fred" on the source 
system
 to the id of a "Fred" on the receiving system there's no 
guarantee that's
 correct.

If there's some way to know that some or all of the IDs on the "foreign" 
filesystem are meaningful, possibly after mapping, the system should 
"adopt" the drive as "local", preserving the IDs, and then use umapfs the 
way it would be on any filesystem.  There's no way to do this correctly 
without external knowledge, though.

>> 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.
>
>This is a bit kludgy and goes against POLA, if the ability exists to
>change it then it should be allowed unless explicitly disabled, it
>would be terribly annoying imo to startup some process or give multiuser
>access to a disk then have to shut everything down in order to properly
>chown something.

There's no ID that could sensibly be written since the IDs on the 
filesystem are from a different ID mapping space so chown() and chgrp() 
MUST fail.  It's not a matter of defaulting of some option.  As for the 
POLA, imagine how surprised the original creator of the filesystem would 
be to find random user/group IDs assigned to files and directories on the 
disk.  I would think that seeing "unknown"/"unknown" for the user and 
group on every file and directory on the "foreign" filesystem should 
reduce the astonishment fact considerably.

>> 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)
>
>This is very interesting, as a timesaver to the second option
>(overwriting) you could use the timestamp on the file's permissions
>to determine if the UID/GIDs are valid (if they are stale old uids,
>or new uid's after a chown/chgrp)

That'd be an intriguing optimization.  It would require maintaining a 
timestamp for every file and directory on the disk to note the time of 
the last change, thou

Re: Apple's planned appoach to permissions on movable filesystems

[Pat Dirks]

>[.]
>> 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).

What do you see as the advantage of explicitly assigning ownership to the 
mounting user/group?  The effect should be the same in either case?  I 
suppose it allows an intereting middle-level of access to the group in 
question?

In the case of Mac OS X we've got a daemon in the system looking for new 
disks being inserted/attached and doing the mount.  We still want the 
console user to have "ownership" of the filesystem in "foreign" mode.

>[.] 
>> 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.

Sorry, I neglected to specify that in my original post.  Given the scheme 
outline in my original post, the plan is precisely to make new files or 
directories be owned by "nobody".  There's no sensible ID that you can 
write onto the filesystem and it makes it easier for the original owner 
to track down new files or directories created on the other system.

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

[Wilfredo Sanchez]

| Please, don't give me this crap. "Removable media" is a very
| well-defined terminology.

  Only in screw-your-device-into-the-machine land.

  We're have to consider hot-swappable devices, including hard disks  
and floppies and video cameras and new-uber-whatzit-media.

-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: bind(2) sets errno to undocumented EAGAIN?

[Charles Randall]

Done. docs/14173

Thanks,
Charles

-Original Message-
From: Archie Cobbs [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, October 06, 1999 11:14 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: 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


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

[Brooks Davis]

On Wed, 6 Oct 1999, Pat Dirks wrote:

> 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.

One question, does the design take in to account a group of machines which
share a set of fs IDs?  I ask because otherwise, you couldn't have adopted
filesystems that work in a computer lab environment where you have no
choice to assume all the machines are identical without some really
extreme pain.

-- Brooks



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

[David Wolfskill]

>Date: Wed, 6 Oct 1999 17:11:41 -0700
>From: Pat Dirks <[EMAIL PROTECTED]>

>>This is very interesting, as a timesaver to the second option
>>(overwriting) you could use the timestamp on the file's permissions
>>to determine if the UID/GIDs are valid (if they are stale old uids,
>>or new uid's after a chown/chgrp)

>That'd be an intriguing optimization.  It would require maintaining a 
>timestamp for every file and directory on the disk to note the time of 
>the last change, though, in addition to the filesystem's timestamp, 
>wouldn't it?  I suppose you could check that the owner/group IDs are 
>corrected if the "last changed date" is ever updated and ignore the 
>owner/group IDs if the last changed date is before the filesystem's 
>timestamp and thereby incrementally update individual 
>filesystems/directories on the filesystem without a lengthy delay at 
>"adoption" time.

Please be careful here.

There is absolutely *no* (meta-)information that can be trusted on a
"foreign" medium, unless one can trust each process (computer-originated
or otherwise) that has had the ability to modify anything on the medium.

[Bad analogy follows.  Sorry, I can't help myself.]  Suppose you give a
kid a sucker.  The kid might keep it in his mouth until it's all
consumed, but that's not especially probable.  More likely, it's
repeatedly placed in his mouth & taken back out.  Often, putting it back
in his mouth is a reasonable thing to do... but it depends on where the
sucker has been in the mean time.

Cheers,
david
-- 
David Wolfskill [EMAIL PROTECTED] UNIX System Administrator
voice: (650) 577-7158   pager: (888) 347-0197   FAX: (650) 372-5915


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Non-standard FFS parameters

[Matthew Dillon]

:> :* 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..

Because you don't gain anything by going higher.  Once you get over a 
certain number fsck's run time is short enough that you no longer care.
Even if you cannot contemplate using more then a few hundred files,
restricting the number of inodes to just that only narrows your options
later on.  The only time you might really care is if you are generating,
say, a boot floppy.

:> 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.

The -i parameter controls the number of inodes, not the block size.
The block size is irrelevant.

:> 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...

UFS/FFS allocates inodes and blocks in the bitmap statistically.  The
algorithm works best when there are plenty inodes in the cylinder group
and enough cylinder groups such that the block bitmaps are not too
large, because the algorithm will become less efficient in such cases.

:> 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)

Well, the kernel itself has a 256KB block size limit.  The types of
problems that will occur with large block sizes are mostly going to
be related to the fact that the buffer cache is not tuned to deal
with large block sizes, not even in -current.  So it will not be
very efficient.  Also, caching large blocks creates inefficiencies in
the VM system because the VM system likes to cache page-sized chunks
(i.e. 4K on i386).  The buffer cache is much less efficient dealing
with large buffers which have had holes poked into them due to the VM
caching algorithms.  

The disks will not be able to transfer file data any faster using large 
blocks verses the default, so beyond a certain point the performance 
simply stops improving.

I would recommend a 16K or 32K block size and the only real reason for
doing it that way is to reduce the number of indirect blockmap blocks
required to maintain the file.

-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

[Wilfredo Sanchez]

| 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."

-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

[Wilfredo Sanchez]

| 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.

  This is becoming less and less true.  One of the driving reasons  
why we're trying to work out this issue is FireWire.  At some point,  
you might expect a computer that uses FireWire for both the internal  
and external drives, and the kernel isn't necessarily going to be  
able to know what's "locked inside" the computer vs what's outside  
the computer; it's (possibly) all one big hot-swappable bus.  Your  
root device could certainly live outside the box.  Distinguishing  
"easily removeable" isn't the way to go here.

-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

[Wilfredo Sanchez]

| 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.

  It's complicated.  We do have a distributed database (NetInfo) and  
we considered perhaps using the name of the NetInfo domain to  
determine local vs. foreign.  The problem is that distributed  
databases are sometimes hierarchical, and can be mixed.  For example:

  Host H1 is in NetInfo domain N1 and has local users U1 and U2 (eg.  
they are in the local host's domain or in /etc/passwd on the local  
host).

  Host H2 is also in N1, but doesn't have local user U1 but it has a  
local user U2, though it's a different person's UID.

  NetInfo domains can be tiered, and so you might shared some, but  
not all, of the NetInfo users.  Also, our resolver can use multiple  
sources, such as NetInfo and Hesiod and NIS.

  This makes keeping track of what IDs might be shared between any  
two machines a hard problem.

-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

[Wilfredo Sanchez]

| 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

[Pat Dirks]

>> 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

[Pat Dirks]

>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)

[Doug]

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

Re: Apple's planned appoach to permissions on movable filesystems

[Alban Hertroys]

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?

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

Re: Apple's planned appoach to permissions on movable filesystems

[Julian Elischer]

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

Re: Apple's planned appoach to permissions on movable filesystems

[Daniel C. Sobral]

Wilfredo Sanchez wrote:
> 
> | 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.
> 
>   This is becoming less and less true.  One of the driving reasons
> why we're trying to work out this issue is FireWire.  At some point,
> you might expect a computer that uses FireWire for both the internal
> and external drives, and the kernel isn't necessarily going to be
> able to know what's "locked inside" the computer vs what's outside
> the computer; it's (possibly) all one big hot-swappable bus.  Your
> root device could certainly live outside the box.  Distinguishing
> "easily removeable" isn't the way to go here.

As I pointed out, the distinction is one of intent on the part of
the admin.

--
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

[Brian Somers]

> >[.]
> >> 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).
> 
> What do you see as the advantage of explicitly assigning ownership to the 
> mounting user/group?  The effect should be the same in either case?  I 
> suppose it allows an intereting middle-level of access to the group in 
> question?
[.]

Well, the idea is that if I personally ``own'' the media, I'll want 
to put the appropriate permissions on files (eg, my private pgp key) 
and then carry it 'round in my back pocket.  I want to be able to 
access that 0600 file after mounting the media and I don't want 
anyone else to.  I think this is ability would be a big plus

In the case of root, they should be able to do all this for any user 
- they can anyway by simply switching uids.

Another thing that now occurs to me is that it should probably be 
possible for root to mount the disk as `user fred' but with groups 
as they are on the disk (and see below) - ie, I'm moving a disk from 
one system to another and those systems share the same groups, but 
not the users.

> In the case of Mac OS X we've got a daemon in the system looking for new 
> disks being inserted/attached and doing the mount.  We still want the 
> console user to have "ownership" of the filesystem in "foreign" mode.
[.]

Ah, ok, so all files belong to that user - I didn't realise you'd 
said that.  This is what I'm after too, but the group side of things 
should be dealt with too so that I can give others group permissions 
to various bits on my disk.

Thinking about it, -g should probably allow some sort of mapping 
syntax where I can say map gid x to gid y and map gid a to gid b 
where I'm a member of groups y and b.  By default, map no groups 
(everything's owned by the magical nobody to which nobody is a 
member)

-- 
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
     <[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