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

[Narvi]

Sorry, this is somewhat late.

On Wed, 6 Oct 1999, Wilfredo Sanchez wrote:

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

Well, people for some reason miss the point. What I was talking about is
the 'interface', and that it be easy to attach things to it.

Site A will want to distribute the ids via hesiod.
Site B will want to distribute the ids via nis+.
Site C wants to do it via Netinfo
Site D wantd to use LDAP.

There may be others (SNMP?).

One way to do this is for example to have:
a) a parameter (by default null) that specifies which program
   to run to get a list of local system ids
b) a parameters (by default null) that specifies which program
   to run if we want to verify if a certain id has been added
   to the set of local ids since the startup.

As the program can be anything (inc. a shell script) almost any way of
distributing the local systems ids can be accomodated. 

This is of course just one way to achieve it (think of PAM).

[snip]

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



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

[Randell Jesup]

Kris Kennaway <[EMAIL PROTECTED]> writes:
>Make uids randomly assigned. This solves the problem of collision between
>uids on an introduced medium and the ones on the local system by making it
>statistical (if the uid space is large enough). In order to manage this
>among multiple machines, you'd probably need a synchronisation facility,
>both online (connect to some network database), and by an "export/import"
>facility which lets you dump a DB and import (parts of) it on another
>machine. Storing the large uid in the inode is probably not feasible w/o
>breaking compatability, but you could indirect it through a mapping table
>loaded from elsewhere on disk when the FS is mounted.
>
>The downside to this is not being able to assign the uids according to
>your own numbering scheme. Perhaps what could be done is to have a lookup
>table which maps between in-system uids and on-disk ones, such that the
>kernel presents the translated uid to the system, and remaps the unknown
>ones.

This is a form of the "how do I know who  is?"

Other interesting ideas (some related to the above):

   Store on the disk a (small) UID to user-name/identifier mapping.  When
   mounting a disk, use those mappings to provide the (super)user with
   the option to map the UID's of users who match the users of files on
   the disk.  There are some issues with identifying whether "joe" is the
   same "joe" on the other system, but when combined with information
   that's currently in passwd, it shouldn't be hard.  You can also provide
   this info to the person mounting the disk in a nice form that they
   can accept, modify, or reject (and mount as totally foreign).  For the
   case of shared user databases, this should always come up with a
   1:1 complete mapping.

   You could extend this to use some form of public-key signature to
   distinguish between users with similar names, and/or query the original
   machine for more info/permission if possible.

   When you mount a disk with UID translation going on, you could also
   change the UID of new/modified files to be that of the user on the 
   new system (and update the user database on the partition), so when the
   disk was moved back the original owner could filter out modifications
   if he so wishes, or 'vet' them.  Note: this includes root; or root can
   be handled specially.


   Much of what's going on here is that the decisions need to be in user
   space, and this allows the software to present the user with a likely
   set of mappings that they can accept, modify or reject.


   If a (non-priviledged) user wants to mount a disk, they should not
   be given any other than "other" access to anything (if that(?)), unless
   they can identify themselves as the same user as one of the users
   on the mounted disk (see above) - depending on how draconian you want
   to be, and what level of security you've configured the disk for.

   (Note: that last may be an important aspect.  When a disk is set up
   in a physically somewhat insecure setup (disk outside box, firewire,
   etc as is being contemplated) you should be able to decide if you want
   the disk to be "movable" or not.  (And change that decision later if
   you want to move it.)


Please excuse the rambling; I was just throwing out some ideas to see
if any stick to the wall.

-- 
Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94)
[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

[Brian Somers]

[.]
> Revisiting security now...
> 
> A provision for public-key encryption of the data held on the disk (as
> well as the id itself) would be useful.  Just encrypting the ID alone
> would not be useful.
> 
> The distinction would then shift away from whether the media is removable
> or not (it would no longer matter as much) and instead assume that no
> unencrypted data can ever be trusted and encrypted data can be trusted
> insofar as the ID can be trusted.
[.]

Too hard !  I would have thought the only practical way would be to 
digitally sign the contents of the disk and then to validate the 
signature before mount time.

IMHO this is nothing to do with the ability to mount removable media. 
If the admin wants this level of paranoia (certainty ?) then {,s}he 
can do it h{im,er}self... at the end of the day, root decides if the 
media is ``local'', not the media.

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

[Kris Kennaway]

Here's a passing thought I had which may be relevant.

Make uids randomly assigned. This solves the problem of collision between
uids on an introduced medium and the ones on the local system by making it
statistical (if the uid space is large enough). In order to manage this
among multiple machines, you'd probably need a synchronisation facility,
both online (connect to some network database), and by an "export/import"
facility which lets you dump a DB and import (parts of) it on another
machine. Storing the large uid in the inode is probably not feasible w/o
breaking compatability, but you could indirect it through a mapping table
loaded from elsewhere on disk when the FS is mounted.

The downside to this is not being able to assign the uids according to
your own numbering scheme. Perhaps what could be done is to have a lookup
table which maps between in-system uids and on-disk ones, such that the
kernel presents the translated uid to the system, and remaps the unknown
ones.

Kris


XOR for AES -- join the campaign!



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]

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

Absolutely.

> --
> Daniel C. Sobral  (8-DCS)
[.]
-- 
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

[Brian Somers]

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

The admin has to ``mount -u'' it local - it should default to foreign.

>   -Fred
> 
> 
> --
>Wilfredo Sanchez, [EMAIL PROTECTED]
> Apple Computer, Inc., Core Operating Systems / BSD
>   Technical Lead, Darwin Project
>1 Infinite Loop, 302-4K, Cupertino, CA 95014

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

[Darren R. Davis]

Matthew Dillon wrote

>
> Revisiting security now...
>
> A provision for public-key encryption of the data held on the disk (as
> well as the id itself) would be useful.  Just encrypting the ID alone
> would not be useful.
>
> The distinction would then shift away from whether the media is removable
> or not (it would no longer matter as much) and instead assume that no
> unencrypted data can ever be trusted and encrypted data can be trusted
> insofar as the ID can be trusted.
>
> Methinks this could result in a very useful project - an 'encrypted' UFS
> filesystem implementation plus domain based services to translate uid's
> on the fly.
>
> -Matt
> Matthew Dillon
> <[EMAIL PROTECTED]>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message

Similar in thought to TCFS.  see http://tcfs.dia.unisa.it/

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

[Matthew Dillon]

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

Ignoring the security issues for the moment, I think putting the
FQDN (fully qualified domain name) of the 'owner' of the disk volume
could prove extremely useful in the new internet age.  As machines
get better connected, such information could eventually be used by
the operating system to translate user id's on the fly by using the
domain name in the label to contact the host in question in order to
obtain the translation.  Something similar to MX DNS records (i.e. a
hierarchically specified 'user translation' service) would glue it all
together.

Baring the availability of a domain name, some sort of unique ID could
potentially serve the same function, but without the ability to look it
up on the internet.  Perhaps the real solution is to allow sites to 
distribute and maintain unique id's based on their domain name, e.g.
FU123BAC@.  These sites could also offer the uid translation
service to its customers.

: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

Revisiting security now...

A provision for public-key encryption of the data held on the disk (as
well as the id itself) would be useful.  Just encrypting the ID alone
would not be useful.

The distinction would then shift away from whether the media is removable
or not (it would no longer matter as much) and instead assume that no
unencrypted data can ever be trusted and encrypted data can be trusted
insofar as the ID can be trusted.

Methinks this could result in a very useful project - an 'encrypted' UFS
filesystem implementation plus domain based services to translate uid's
on the fly.

-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

[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

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

[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

[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

[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

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

[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

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

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

| 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

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

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

[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

[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

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

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

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

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

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: 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: 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: Apple's planned appoach to permissions on movable filesystems

[David Scheidt]

On Tue, 5 Oct 1999, Pat Dirks wrote:

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

What about allowing a mapping of the foreign filesystem IDs to local IDs
when the filesystem is adopted.  A user might well prepare a filesystem on
one machine, and then want to use it permently on this.  Something that
would allow foreign filesystems with key X get uid 1001 mapped to 6002, and
uid 1002 to 4534, everything else goes to unknown.  This is easier than
having to do chown -R everytime some carries a removable filesystem from
home to work, or vice versa.

> 
> 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 would think you want this the default behavior.


David Scheidt, waiting till Mac OS X to replace his Quadra 605.



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

[Alfred Perlstein]

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.

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

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

-Alfred



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: Tue, 5 Oct 1999 14:19:22 -0700
>From: Pat Dirks <[EMAIL PROTECTED]>

>[Lots of interesting, useful stuff elided -- dhw]

>ADOPTING "FOREIGN" FILESYSTEMS

>...

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

Actually, I would expect that from a security/integrity perspective, one
would want the default to be that a re-introduced disk would be considered
"foreign".

This might seem unfriendly to some, but unless you really know where the
medium has been, there's no basis for trusting its content any more than
any other random (but otherwise equivalent) medium.

A mechanism for overriding this presumption could be useful, if used in
sufficient moderation.

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