Re: Need some advice regarding portable user IDs
[ tech-userle...@netbsd.org removed from cc:, it's not a userlevel issue any more ] On Tue, Aug 24, 1999 at 07:49:02PM +0100, Neil A. Carson wrote: > ext2fs in Linux already has some support for mount downgrading or forcable > unomunting (maybe) in the case of an FS error. For something like a > floppy, it ought to be possible to force-unmount the disc in the event of > a metadata error. And, to my experience this is not a good feature (but I think it's an implementation issue). A HD error left one of my machine with a root filesystem in an unusable state. I had to boot a netbsd floppy to recover data from other partitions (which didn't have errors :) -- Manuel Bouyer, LIP6, Universite Paris VI. manuel.bou...@lip6.fr -- To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
[ [EMAIL PROTECTED] removed from cc:, it's not a userlevel issue any more ] On Tue, Aug 24, 1999 at 07:49:02PM +0100, Neil A. Carson wrote: > ext2fs in Linux already has some support for mount downgrading or forcable > unomunting (maybe) in the case of an FS error. For something like a > floppy, it ought to be possible to force-unmount the disc in the event of > a metadata error. And, to my experience this is not a good feature (but I think it's an implementation issue). A HD error left one of my machine with a root filesystem in an unusable state. I had to boot a netbsd floppy to recover data from other partitions (which didn't have errors :) -- Manuel Bouyer, LIP6, Universite Paris VI. [EMAIL PROTECTED] -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
ext2fs in Linux already has some support for mount downgrading or forcable unomunting (maybe) in the case of an FS error. For something like a floppy, it ought to be possible to force-unmount the disc in the event of a metadata error. Neil To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
ext2fs in Linux already has some support for mount downgrading or forcable unomunting (maybe) in the case of an FS error. For something like a floppy, it ought to be possible to force-unmount the disc in the event of a metadata error. Neil To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
>> Solving this is not trivial, I don't think changing the panic() to >> return(appropriate_error_code) is the rigth thing to do, in some >> case you want to panic if a filesystem gets corrupted. > [...consider / or /usr...] I think an error return is preferable to a panic, during the mount operation. During normal operation, it seems to me that the right thing is to panic if the mount was done by root and to do the forcible-unmount thing if non-root. (This arguably should be a mount option which is forced on for non-root mounts, so that root mounts can get the force-unmount semantics if desired.) der Mouse mo...@rodents.montreal.qc.ca 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
> Solving this is not trivial, I don't think changing the panic() to > return(appropriate_error_code) is the rigth thing to do, in some case > you want to panic if a filesystem gets corrupted. Indeed, from an overall system robustness perspective, a panic, reboot, and salvage is, in general, preferable to a forced-unmount of / or /usr leading to the system becoming useless.. This isn't necessarily going to be the case for other filesystems, but still, it would require manual intervention to recover from. This problem has been dealt with in various ways in other systems in the past. My understanding is that under some circumstances, Multics would automatically invoke an on-line incremental salvager when corruption was detected; however, this can also be dangerous -- several multics security holes (which were all eventually closed) involved tricking the directory salvager in various ways... one of these involved a quoting error in the script which invoked the salvager so that you could embed a ";" followed by a command in the name of the directory to be salvaged... - Bill To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
Just FYI, in NetBSD-current, there are on the order of 60 calls to panic() in sys/ufs/ufs, and 50 calls to panic() in sys/ufs/ffs. There appear to be similar numbers in ext2fs and lfs. No doubt some of them are internal consistancy checks which can't be triggered by on-disk corruption, but still, this sounds like a substantial project.. - Bill To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
On Tue, Aug 24, 1999 at 03:15:09PM +0200, Wolfgang Solfrank wrote: > Hmm, I think the appropriate thing to do is some equivalent of "panic"ing, > but only for the filesystem in question. I.e. something like forcibly > unmounting that filesystem (but maybe continue to return EIO on access to > anything below the mountpoint?). Whether to flush dirty buffers for the > filesystem in question out or not, I'm not sure about either. I'm not sure. I think if this happens on a non-removable hard drive, a panic is the rigth thing to do. You'll get a core dump, and it's not necesserely a good thing to let a server operate without all it's filesystems. On my shell server, if /var gets corrupted, I'm sure I prefer to get a panic instead of letting it run without accounting. -- Manuel Bouyer, LIP6, Universite Paris VI. manuel.bou...@lip6.fr -- To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
Hi, > > What I meant to say was that code of the various filesystems currently > > assumes that the data on the media is somewhat consistent. Since the > > intention is that Joe User can mount some arbitrary floppy (or zip disk, > > or ...), the in kernel filesystem code needs to check any data it > > reads off the media for plausibility. [...] > Solving this is not trivial, I don't think changing the panic() to > return(appropriate_error_code) is the rigth thing to do, in some case > you want to panic if a filesystem gets corrupted. This could probably > be switched on/off for root/non-root mounts. > Also I think there are some cases where it's too late to recover gracefully. Hmm, I think the appropriate thing to do is some equivalent of "panic"ing, but only for the filesystem in question. I.e. something like forcibly unmounting that filesystem (but maybe continue to return EIO on access to anything below the mountpoint?). Whether to flush dirty buffers for the filesystem in question out or not, I'm not sure about either. Ciao, Wolfgang -- w...@tools.de (Wolfgang Solfrank, TooLs GmbH) +49-228-985800 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
On Tue, Aug 17, 1999 at 07:17:45PM -0700, Wilfredo Sanchez wrote: > [...] > > I think the desired behaviour would be that since this is > effectively now Joe's zip disk, he should be able to do as he > pleases. One proposal might be to give the console user the > equivalent of root's priveledges on any removeable media he inserts > into the machine while he's logged in on the console. This solves > the immediate problem of permissions for Joe, since the file owners > are, on his machine and in this situation, largely irrelevant. > Presumably the console user is the one fiddling with the external > media. > What I would do here is give root privileges to the user who mounted the filesystem, for this filesystem. As in 4.4BSD non-root users can mount media if they have access to the block device, I think this would solve this problem. -- Manuel Bouyer, LIP6, Universite Paris VI. manuel.bou...@lip6.fr -- To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
On Tue, Aug 24, 1999 at 02:59:09PM +0200, Wolfgang Solfrank wrote: > [...] > What I meant to say was that code of the various filesystems currently > assumes that the data on the media is somewhat consistent. Since the > intention is that Joe User can mount some arbitrary floppy (or zip disk, > or ...), the in kernel filesystem code needs to check any data it > reads off the media for plausibility. Sure, at last for some filesystems it's possible to crash the machine with a bad FS on a media. But you trust your users don't you ? :) Solving this is not trivial, I don't think changing the panic() to return(appropriate_error_code) is the rigth thing to do, in some case you want to panic if a filesystem gets corrupted. This could probably be switched on/off for root/non-root mounts. Also I think there are some cases where it's too late to recover gracefully. -- Manuel Bouyer, LIP6, Universite Paris VI. manuel.bou...@lip6.fr -- To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
>> Solving this is not trivial, I don't think changing the panic() to >> return(appropriate_error_code) is the rigth thing to do, in some >> case you want to panic if a filesystem gets corrupted. > [...consider / or /usr...] I think an error return is preferable to a panic, during the mount operation. During normal operation, it seems to me that the right thing is to panic if the mount was done by root and to do the forcible-unmount thing if non-root. (This arguably should be a mount option which is forced on for non-root mounts, so that root mounts can get the force-unmount semantics if desired.) der Mouse [EMAIL PROTECTED] 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
Hi, > > BTW, since non-root users can mount anything, we should make the > > filesystems' > > code more robust, so that one cannot take the machine down by inserting > > random media and mounting it. > > They can't mount anything, they need to have access to the block devices. Of course there are some restrictions. What I meant to say was that code of the various filesystems currently assumes that the data on the media is somewhat consistent. Since the intention is that Joe User can mount some arbitrary floppy (or zip disk, or ...), the in kernel filesystem code needs to check any data it reads off the media for plausibility. Ciao, Wolfgang -- w...@tools.de (Wolfgang Solfrank, TooLs GmbH) +49-228-985800 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
> Solving this is not trivial, I don't think changing the panic() to > return(appropriate_error_code) is the rigth thing to do, in some case > you want to panic if a filesystem gets corrupted. Indeed, from an overall system robustness perspective, a panic, reboot, and salvage is, in general, preferable to a forced-unmount of / or /usr leading to the system becoming useless.. This isn't necessarily going to be the case for other filesystems, but still, it would require manual intervention to recover from. This problem has been dealt with in various ways in other systems in the past. My understanding is that under some circumstances, Multics would automatically invoke an on-line incremental salvager when corruption was detected; however, this can also be dangerous -- several multics security holes (which were all eventually closed) involved tricking the directory salvager in various ways... one of these involved a quoting error in the script which invoked the salvager so that you could embed a ";" followed by a command in the name of the directory to be salvaged... - Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
>> BTW, since non-root users can mount anything, we should make the >> filesystems' code more robust, so that one cannot take the machine >> down by inserting random media and mounting it. > They can't mount anything, they need to have access to the block > devices. It is not unreasonable for vanilla users to have read/write access to the block devices for removable media (floppies, zip disks, etc). From what I hear, it's not even particularly uncommon. der Mouse mo...@rodents.montreal.qc.ca 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
Just FYI, in NetBSD-current, there are on the order of 60 calls to panic() in sys/ufs/ufs, and 50 calls to panic() in sys/ufs/ffs. There appear to be similar numbers in ext2fs and lfs. No doubt some of them are internal consistancy checks which can't be triggered by on-disk corruption, but still, this sounds like a substantial project.. - Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
On Tue, Aug 24, 1999 at 03:15:09PM +0200, Wolfgang Solfrank wrote: > Hmm, I think the appropriate thing to do is some equivalent of "panic"ing, > but only for the filesystem in question. I.e. something like forcibly > unmounting that filesystem (but maybe continue to return EIO on access to > anything below the mountpoint?). Whether to flush dirty buffers for the > filesystem in question out or not, I'm not sure about either. I'm not sure. I think if this happens on a non-removable hard drive, a panic is the rigth thing to do. You'll get a core dump, and it's not necesserely a good thing to let a server operate without all it's filesystems. On my shell server, if /var gets corrupted, I'm sure I prefer to get a panic instead of letting it run without accounting. -- Manuel Bouyer, LIP6, Universite Paris VI. [EMAIL PROTECTED] -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
On Thu, Aug 19, 1999 at 02:17:49PM +0200, Wolfgang Solfrank wrote: > BTW, since non-root users can mount anything, we should make the filesystems' > code more robust, so that one cannot take the machine down by inserting > random media and mounting it. They can't mount anything, they need to have access to the block devices. For "loopback" mounts (null, union, umap, ...), we have to be more carefull about restrictions. Maybe NFS is an issue too ... -- Manuel Bouyer, LIP6, Universite Paris VI. manuel.bou...@lip6.fr -- To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
Hi, > > What I meant to say was that code of the various filesystems currently > > assumes that the data on the media is somewhat consistent. Since the > > intention is that Joe User can mount some arbitrary floppy (or zip disk, > > or ...), the in kernel filesystem code needs to check any data it > > reads off the media for plausibility. [...] > Solving this is not trivial, I don't think changing the panic() to > return(appropriate_error_code) is the rigth thing to do, in some case > you want to panic if a filesystem gets corrupted. This could probably > be switched on/off for root/non-root mounts. > Also I think there are some cases where it's too late to recover gracefully. Hmm, I think the appropriate thing to do is some equivalent of "panic"ing, but only for the filesystem in question. I.e. something like forcibly unmounting that filesystem (but maybe continue to return EIO on access to anything below the mountpoint?). Whether to flush dirty buffers for the filesystem in question out or not, I'm not sure about either. Ciao, Wolfgang -- [EMAIL PROTECTED] (Wolfgang Solfrank, TooLs GmbH) +49-228-985800 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
On Tue, Aug 17, 1999 at 07:17:45PM -0700, Wilfredo Sanchez wrote: > [...] > > I think the desired behaviour would be that since this is > effectively now Joe's zip disk, he should be able to do as he > pleases. One proposal might be to give the console user the > equivalent of root's priveledges on any removeable media he inserts > into the machine while he's logged in on the console. This solves > the immediate problem of permissions for Joe, since the file owners > are, on his machine and in this situation, largely irrelevant. > Presumably the console user is the one fiddling with the external > media. > What I would do here is give root privileges to the user who mounted the filesystem, for this filesystem. As in 4.4BSD non-root users can mount media if they have access to the block device, I think this would solve this problem. -- Manuel Bouyer, LIP6, Universite Paris VI. [EMAIL PROTECTED] -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
On Tue, Aug 24, 1999 at 02:59:09PM +0200, Wolfgang Solfrank wrote: > [...] > What I meant to say was that code of the various filesystems currently > assumes that the data on the media is somewhat consistent. Since the > intention is that Joe User can mount some arbitrary floppy (or zip disk, > or ...), the in kernel filesystem code needs to check any data it > reads off the media for plausibility. Sure, at last for some filesystems it's possible to crash the machine with a bad FS on a media. But you trust your users don't you ? :) Solving this is not trivial, I don't think changing the panic() to return(appropriate_error_code) is the rigth thing to do, in some case you want to panic if a filesystem gets corrupted. This could probably be switched on/off for root/non-root mounts. Also I think there are some cases where it's too late to recover gracefully. -- Manuel Bouyer, LIP6, Universite Paris VI. [EMAIL PROTECTED] -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
Hi, > > BTW, since non-root users can mount anything, we should make the filesystems' > > code more robust, so that one cannot take the machine down by inserting > > random media and mounting it. > > They can't mount anything, they need to have access to the block devices. Of course there are some restrictions. What I meant to say was that code of the various filesystems currently assumes that the data on the media is somewhat consistent. Since the intention is that Joe User can mount some arbitrary floppy (or zip disk, or ...), the in kernel filesystem code needs to check any data it reads off the media for plausibility. Ciao, Wolfgang -- [EMAIL PROTECTED] (Wolfgang Solfrank, TooLs GmbH) +49-228-985800 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
>> BTW, since non-root users can mount anything, we should make the >> filesystems' code more robust, so that one cannot take the machine >> down by inserting random media and mounting it. > They can't mount anything, they need to have access to the block > devices. It is not unreasonable for vanilla users to have read/write access to the block devices for removable media (floppies, zip disks, etc). From what I hear, it's not even particularly uncommon. der Mouse [EMAIL PROTECTED] 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
On Thu, Aug 19, 1999 at 02:17:49PM +0200, Wolfgang Solfrank wrote: > BTW, since non-root users can mount anything, we should make the filesystems' > code more robust, so that one cannot take the machine down by inserting > random media and mounting it. They can't mount anything, they need to have access to the block devices. For "loopback" mounts (null, union, umap, ...), we have to be more carefull about restrictions. Maybe NFS is an issue too ... -- Manuel Bouyer, LIP6, Universite Paris VI. [EMAIL PROTECTED] -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
On Tue, 17 Aug 1999, Brian C. Grayson wrote: > On Tue, Aug 17, 1999 at 07:17:45PM -0700, Wilfredo Sanchez wrote: > > A group of us at Apple are trying to figure out how to handle > > situations where a filesystem with "foreign" user ID's are present. > > Have you looked at mount_umap(8)? I (naively) think it would > solve most of your concerns. I don't think so. umap is for translating credentials between domains. I think what Fred wants to do is different, and that is to ignore the credentials on the system. Fred, right now what happens in MacOS when I take a disk which has sharing credentials set up, and hook it into another machine? How are the credentials handled there? Also, one of the problems which has been brought up in the thread is that umap needs to know what credentials to translate to. For that, we'd need to stash the credentails on the drive. Take care, Bill To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
Wilfredo Sanchez wrote: > > A group of us at Apple are trying to figure out how to handle > situations where a filesystem with "foreign" user ID's are present. > The basic problem is that the user experience using Unix semantics > are not really pleasant. I think some examples would help: > > I'm working with Joe on a project, and I have some sources I want > him to take a look at, so I mount a floppy disk. Well, that's a bad > example, because floppies are "out"... So I mount a zip disk with UFS > on it, and I copy my source tree onto it, and hand this to Joe. Joe > takes the disk home, and sticks it in his computer, and he finds > that he can't read the files, because I have a lamer umask, and as a > bonus, I don't have an account on his machine, so the files are owned > by some random UID. Having run into this problem myself, both with tar'ed archives and zip disks I came up with the following dream world one day. In my world there are two magic uid's, one for a "read only" user and one for a "read write" user. If I give Joe a zip disk with my files on it all owned by my uid, by default when he puts it in his drive at his workstation it comes up with all files owned by the read only user. He can read the files, copy them to his work station, etc. but he can't make changes to the existing files. If I want to let Joe change the files on my disk I can set the rw flag, so when he pops it in his drive it comes up owned by the "read write" user. (Still assuming that Joe and I have mismatched uid's.) In a system like this I'd also like to see a flag that lets the owner require that the uid semantics are enforced. Also, the flags should be settable on the file, directory and disk levels. Finally in an ultra-paranoid environment you could set an option that requires that the uid matchup is for the actual person, similar to the way an ssh public key/private key pair works. Hope this is useful, Doug To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
Wilfredo Sanchez wrote: > > A group of us at Apple are trying to figure out how to handle > situations where a filesystem with "foreign" user ID's are present. > The basic problem is that the user experience using Unix semantics > are not really pleasant. I think some examples would help: > > I'm working with Joe on a project, and I have some sources I want > him to take a look at, so I mount a floppy disk. Well, that's a bad > example, because floppies are "out"... So I mount a zip disk with UFS > on it, and I copy my source tree onto it, and hand this to Joe. Joe > takes the disk home, and sticks it in his computer, and he finds > that he can't read the files, because I have a lamer umask, and as a > bonus, I don't have an account on his machine, so the files are owned > by some random UID. Having run into this problem myself, both with tar'ed archives and zip disks I came up with the following dream world one day. In my world there are two magic uid's, one for a "read only" user and one for a "read write" user. If I give Joe a zip disk with my files on it all owned by my uid, by default when he puts it in his drive at his workstation it comes up with all files owned by the read only user. He can read the files, copy them to his work station, etc. but he can't make changes to the existing files. If I want to let Joe change the files on my disk I can set the rw flag, so when he pops it in his drive it comes up owned by the "read write" user. (Still assuming that Joe and I have mismatched uid's.) In a system like this I'd also like to see a flag that lets the owner require that the uid semantics are enforced. Also, the flags should be settable on the file, directory and disk levels. Finally in an ultra-paranoid environment you could set an option that requires that the uid matchup is for the actual person, similar to the way an ssh public key/private key pair works. Hope this is useful, Doug 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: Need some advice regarding portable user IDs
On Wed, 18 Aug 1999, Marc Ramirez wrote: > Oh! I was under the impression that it just didn't work, even with > correct perms, but I use FreeBSD. Lemme try it... Can't mount, even > with 0666 on /dev/fd0. Maybe I'm being stupid. Wouldn't be the first > time! It's controlled by a sysctl in FreeBSD which defaults to "off" - I forget what it is called. Kris To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
On Tue, 17 Aug 1999, Brian C. Grayson wrote: > On Tue, Aug 17, 1999 at 07:17:45PM -0700, Wilfredo Sanchez wrote: > > A group of us at Apple are trying to figure out how to handle > > situations where a filesystem with "foreign" user ID's are present. > > Have you looked at mount_umap(8)? I (naively) think it would > solve most of your concerns. I don't think so. umap is for translating credentials between domains. I think what Fred wants to do is different, and that is to ignore the credentials on the system. Fred, right now what happens in MacOS when I take a disk which has sharing credentials set up, and hook it into another machine? How are the credentials handled there? Also, one of the problems which has been brought up in the thread is that umap needs to know what credentials to translate to. For that, we'd need to stash the credentails on the drive. Take care, Bill 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: Need some advice regarding portable user IDs
On Wed, 18 Aug 1999, Marc Ramirez wrote: > Oh! I was under the impression that it just didn't work, even with > correct perms, but I use FreeBSD. Lemme try it... Can't mount, even > with 0666 on /dev/fd0. Maybe I'm being stupid. Wouldn't be the first > time! It's controlled by a sysctl in FreeBSD which defaults to "off" - I forget what it is called. Kris 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: Need some advice regarding portable user IDs
"Justin C. Walker" wrote: > > My understanding of File Sharing [for Mac OS 8]is that (a) Mac OS > doesn't understand identity, permissions, etc., so it can't "talk" > about them; and (b) when you share a volume from a remote server, you > "login" to that volume using a mechanism supported by the server. For NFS, this is typically pcnfsd on the PC side, and a pcnfsd client on the Mac. > The client system isn't involved. Since you, at the keyboard, are > really the only user of that system, the issue of what "another > logged-in user" can do is moot. This is not true if the user is someone else 10 minutes later. > Note that although the "enhanced" HFS supports credentials (i.e, > owner and group identity), Mac OS doesn't use this capability, and > wouldn't know what to do with a volume that had this info filled in > (i.e., can't make use of it). > > The whole issue of associating identity with permission is a bit > perplexing. DCE attempted to solve this problem, and it got quickly > out of hand. Regardless of whether you are using 32-bit integers, or > 8-character login names, there's little or no guarantee that when > you move a device containing this info from one site to another, the > "mapping" from that identity to who you are will remain valid. There is no guarantee. My uid here is 1001 because mine was the first account added to each of the FreeBSD machines here. At work, it's my employee number. > In the meanwhile, there ought to be a simple version of this problem > that we can solve :-}. I think I'll get down off this soap box for > a bit... pcnfsd? Open source versions have existed for years, at least the server side. If you have the server, a client shouldn't be all that hard to do. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ w...@softweyr.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
"Justin C. Walker" wrote: > > My understanding of File Sharing [for Mac OS 8]is that (a) Mac OS > doesn't understand identity, permissions, etc., so it can't "talk" > about them; and (b) when you share a volume from a remote server, you > "login" to that volume using a mechanism supported by the server. For NFS, this is typically pcnfsd on the PC side, and a pcnfsd client on the Mac. > The client system isn't involved. Since you, at the keyboard, are > really the only user of that system, the issue of what "another > logged-in user" can do is moot. This is not true if the user is someone else 10 minutes later. > Note that although the "enhanced" HFS supports credentials (i.e, > owner and group identity), Mac OS doesn't use this capability, and > wouldn't know what to do with a volume that had this info filled in > (i.e., can't make use of it). > > The whole issue of associating identity with permission is a bit > perplexing. DCE attempted to solve this problem, and it got quickly > out of hand. Regardless of whether you are using 32-bit integers, or > 8-character login names, there's little or no guarantee that when > you move a device containing this info from one site to another, the > "mapping" from that identity to who you are will remain valid. There is no guarantee. My uid here is 1001 because mine was the first account added to each of the FreeBSD machines here. At work, it's my employee number. > In the meanwhile, there ought to be a simple version of this problem > that we can solve :-}. I think I'll get down off this soap box for > a bit... pcnfsd? Open source versions have existed for years, at least the server side. If you have the server, a client shouldn't be all that hard to do. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
> From: Wilfredo Sanchez > Date: 1999-08-18 14:28:54 -0700 > To: Bill Studenmund > Subject: Re: Need some advice regarding portable user IDs > Cc: "Brian C. Grayson" > ,freebsd-hackers@FreeBSD.ORG, > tech-userle...@netbsd.org, p...@apple.com,warne...@apple.com, > ume...@apple.com > In-reply-to: <19990817213718.a28...@marvin.ece.utexas.edu> > X-Loop: FreeBSD.ORG > Delivered-to: freebsd-hackers@freebsd.org > X-Mailer: by Apple MailViewer (2.106) > X-Mailer-Extensions: SWSignature 1.3.2 > > | Fred, right now what happens in MacOS when I take a disk which has > sharing > | credentials set up, and hook it into another machine? How are the > | credentials handled there? > > I think Mac OS 8 will forget about the credentials. I don't > actually know much about how sharing works. > > But the current file sharing behaviour is not entirely useful to > think about, because it doesn't effect the local permissions (much), > and the local permission are what I'm worried about. Exported > filesystems are another story, and I don't want to compilcate things > too much by worrying about that right now. My understanding of File Sharing [for Mac OS 8]is that (a) Mac OS doesn't understand identity, permissions, etc., so it can't "talk" about them; and (b) when you share a volume from a remote server, you "login" to that volume using a mechanism supported by the server. The client system isn't involved. Since you, at the keyboard, are really the only user of that system, the issue of what "another logged-in user" can do is moot. Note that although the "enhanced" HFS supports credentials (i.e, owner and group identity), Mac OS doesn't use this capability, and wouldn't know what to do with a volume that had this info filled in (i.e., can't make use of it). The whole issue of associating identity with permission is a bit perplexing. DCE attempted to solve this problem, and it got quickly out of hand. Regardless of whether you are using 32-bit integers, or 8-character login names, there's little or no guarantee that when you move a device containing this info from one site to another, the "mapping" from that identity to who you are will remain valid. In the meanwhile, there ought to be a simple version of this problem that we can solve :-}. I think I'll get down off this soap box for a bit... Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | Manager, CoreOS Networking| When crypto is outlawed, Apple Computer, Inc. | Only outlaws will have crypto. 2 Infinite Loop | Cupertino, CA 95014 | *-*---* To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
> From: Wilfredo Sanchez <[EMAIL PROTECTED]> > Date: 1999-08-18 14:28:54 -0700 > To: Bill Studenmund <[EMAIL PROTECTED]> > Subject: Re: Need some advice regarding portable user IDs > Cc: "Brian C. Grayson" > <[EMAIL PROTECTED]>,[EMAIL PROTECTED], > [EMAIL PROTECTED], [EMAIL PROTECTED],[EMAIL PROTECTED], > [EMAIL PROTECTED] > In-reply-to: <[EMAIL PROTECTED]> > X-Loop: FreeBSD.ORG > Delivered-to: [EMAIL PROTECTED] > X-Mailer: by Apple MailViewer (2.106) > X-Mailer-Extensions: SWSignature 1.3.2 > > | Fred, right now what happens in MacOS when I take a disk which has > sharing > | credentials set up, and hook it into another machine? How are the > | credentials handled there? > > I think Mac OS 8 will forget about the credentials. I don't > actually know much about how sharing works. > > But the current file sharing behaviour is not entirely useful to > think about, because it doesn't effect the local permissions (much), > and the local permission are what I'm worried about. Exported > filesystems are another story, and I don't want to compilcate things > too much by worrying about that right now. My understanding of File Sharing [for Mac OS 8]is that (a) Mac OS doesn't understand identity, permissions, etc., so it can't "talk" about them; and (b) when you share a volume from a remote server, you "login" to that volume using a mechanism supported by the server. The client system isn't involved. Since you, at the keyboard, are really the only user of that system, the issue of what "another logged-in user" can do is moot. Note that although the "enhanced" HFS supports credentials (i.e, owner and group identity), Mac OS doesn't use this capability, and wouldn't know what to do with a volume that had this info filled in (i.e., can't make use of it). The whole issue of associating identity with permission is a bit perplexing. DCE attempted to solve this problem, and it got quickly out of hand. Regardless of whether you are using 32-bit integers, or 8-character login names, there's little or no guarantee that when you move a device containing this info from one site to another, the "mapping" from that identity to who you are will remain valid. In the meanwhile, there ought to be a simple version of this problem that we can solve :-}. I think I'll get down off this soap box for a bit... Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | Manager, CoreOS Networking| When crypto is outlawed, Apple Computer, Inc. | Only outlaws will have crypto. 2 Infinite Loop | Cupertino, CA 95014 | *-*---* To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
[clipping CC list to include @freebsd.org, @netbsd.org, and @apple.com] > "Chris" == Chris Dillon writes: Chris> An origin filesystem (created by and mounted on the same system) which Chris> happens to have stuff owned by several different users (this is all Chris> pseudo... don't mind sizes, dates, and link counts in this example): Chris> drwxr-xr-x 4 root wheel512 Aug 18 15:42 ./ Chris> drwxr-x--- 4 harry users512 Mar 10 10:21 dir1/ Chris> drwxr-xr-x 2 john users512 Jul 1 18:40 dir2/ Chris> ls -la dir1 Chris> -rw-r- 1 harry users0 Aug 18 15:48 bar Chris> -rw-r- 1 harry users0 Aug 18 15:48 foo Chris> Take this filesystem and mount it as a "foreign" filesystem on another Chris> machine. User 'jake' owns the mountpoint on the machine. Chris> drwxr-xr-x 2 jake users512 Jan 4 1999 /mnt/ Chris> mount_foreign /dev/whatever /mnt Chris> ls -la /mnt Chris> drwxr-xr-x 4 jake users512 Aug 18 15:42 ./ Chris> drwxr-x--- 4 jake users512 Mar 10 10:21 dir1/ Chris> drwxr-xr-x 2 jake users512 Jul 1 18:40 dir2/ Chris> ls -la /mnt/dir1/ Chris> -rw-r- 1 jake users0 Aug 18 15:48 bar Chris> -rw-r- 1 jake users0 Aug 18 15:48 foo Chris> Note file mode bits were not affected, but everything gained the Chris> user/group of the mountpoint. I agree up to this point. Chris> Now what happens if user 'jake' adds something to the filesystem? Chris> touch /mnt/dir1/baz Chris> ls -la /mnt/dir1/ Chris> -rw-r- 1 jake users0 Aug 18 15:48 bar Chris> -rw-r- 1 jake users0 Aug 18 15:48 foo Chris> -rw-r- 1 jake users0 Aug 18 15:50 baz >> From jake's perspective, this happens as if it were an origin Chris> filesystem and he owned everything on it. Chris> Now, mount the filesystem again on it's origin system. First, a question: if the disk was mounted by root on the origin system, then I'm not sure it is safe to mount it again after it has been in another's hand. I would suggest that to facilitate cooperation, that the new file should be made with "jake"'s userid. That may conflict, but I suggest that this is a higher level issue. Chris> 1) When writing to a foreign filesystem, should file mode bits Chris> be inherited from the parent, or be based on the umask of the foreign Chris> user writing the file at that time? Can the umask of the foreign Chris> owner be preserved (which isn't necessarily the same thing as Chris> inheriting from the parent) and used? I'd say you leave things as is for a file system now. Chris> 2) How should chown and chgrp act when attempting to modify Chris> credentials on one of these foreign filesystems? Should it affect Chris> only the local credential mapping (temporarily) and not modify the Chris> foreign filesystem? Should you completely ignore the attempts and I suggest that they fail as non-root can't do chown. If you are root doing this, then you have no problem, but you don't mount as root. chgrp continues to function as normal, which may be wrong if groupids aren't shared, but I suggest that is too, a higher level problem. Chris> 3) What happens if you want to mount the filesystem on a Chris> machine besides the origin, but you do NOT want to do credential Chris> mapping (i.e. the systems both have the same sets of users)? This Chris> wouldn't matter if you just used a mount option or different Chris> filesystem type when mounting, but I'm assuming something automagic is Chris> wanted here. You have to mount as root. Chris> 4) What happens if you change the credentials of the Chris> mountpoint after you have mounted the foreign filesystem? Should the Chris> mappings follow the new credentials, or stay as they were when first Chris> mounted? It requires some kind of mount/umount operation. It might be as simple as doing: "eject floppy" which will fail because the file system is mounted, but it will then reexamine the mount point. :!mcr!:| Cow#1: Are you worried about getting Mad Cow Disease? Michael Richardson | Cow#2: No. I'm a duck. Home: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html";>m...@sandelman.ottawa.on.ca. PGP key available. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
[clipping CC list to include @freebsd.org, @netbsd.org, and @apple.com] > "Chris" == Chris Dillon <[EMAIL PROTECTED]> writes: Chris> An origin filesystem (created by and mounted on the same system) which Chris> happens to have stuff owned by several different users (this is all Chris> pseudo... don't mind sizes, dates, and link counts in this example): Chris> drwxr-xr-x 4 root wheel512 Aug 18 15:42 ./ Chris> drwxr-x--- 4 harry users512 Mar 10 10:21 dir1/ Chris> drwxr-xr-x 2 john users512 Jul 1 18:40 dir2/ Chris> ls -la dir1 Chris> -rw-r- 1 harry users0 Aug 18 15:48 bar Chris> -rw-r- 1 harry users0 Aug 18 15:48 foo Chris> Take this filesystem and mount it as a "foreign" filesystem on another Chris> machine. User 'jake' owns the mountpoint on the machine. Chris> drwxr-xr-x 2 jake users512 Jan 4 1999 /mnt/ Chris> mount_foreign /dev/whatever /mnt Chris> ls -la /mnt Chris> drwxr-xr-x 4 jake users512 Aug 18 15:42 ./ Chris> drwxr-x--- 4 jake users512 Mar 10 10:21 dir1/ Chris> drwxr-xr-x 2 jake users512 Jul 1 18:40 dir2/ Chris> ls -la /mnt/dir1/ Chris> -rw-r- 1 jake users0 Aug 18 15:48 bar Chris> -rw-r- 1 jake users0 Aug 18 15:48 foo Chris> Note file mode bits were not affected, but everything gained the Chris> user/group of the mountpoint. I agree up to this point. Chris> Now what happens if user 'jake' adds something to the filesystem? Chris> touch /mnt/dir1/baz Chris> ls -la /mnt/dir1/ Chris> -rw-r- 1 jake users0 Aug 18 15:48 bar Chris> -rw-r- 1 jake users0 Aug 18 15:48 foo Chris> -rw-r- 1 jake users0 Aug 18 15:50 baz >> From jake's perspective, this happens as if it were an origin Chris> filesystem and he owned everything on it. Chris> Now, mount the filesystem again on it's origin system. First, a question: if the disk was mounted by root on the origin system, then I'm not sure it is safe to mount it again after it has been in another's hand. I would suggest that to facilitate cooperation, that the new file should be made with "jake"'s userid. That may conflict, but I suggest that this is a higher level issue. Chris> 1) When writing to a foreign filesystem, should file mode bits Chris> be inherited from the parent, or be based on the umask of the foreign Chris> user writing the file at that time? Can the umask of the foreign Chris> owner be preserved (which isn't necessarily the same thing as Chris> inheriting from the parent) and used? I'd say you leave things as is for a file system now. Chris> 2) How should chown and chgrp act when attempting to modify Chris> credentials on one of these foreign filesystems? Should it affect Chris> only the local credential mapping (temporarily) and not modify the Chris> foreign filesystem? Should you completely ignore the attempts and I suggest that they fail as non-root can't do chown. If you are root doing this, then you have no problem, but you don't mount as root. chgrp continues to function as normal, which may be wrong if groupids aren't shared, but I suggest that is too, a higher level problem. Chris> 3) What happens if you want to mount the filesystem on a Chris> machine besides the origin, but you do NOT want to do credential Chris> mapping (i.e. the systems both have the same sets of users)? This Chris> wouldn't matter if you just used a mount option or different Chris> filesystem type when mounting, but I'm assuming something automagic is Chris> wanted here. You have to mount as root. Chris> 4) What happens if you change the credentials of the Chris> mountpoint after you have mounted the foreign filesystem? Should the Chris> mappings follow the new credentials, or stay as they were when first Chris> mounted? It requires some kind of mount/umount operation. It might be as simple as doing: "eject floppy" which will fail because the file system is mounted, but it will then reexamine the mount point. :!mcr!:| Cow#1: Are you worried about getting Mad Cow Disease? Michael Richardson | Cow#2: No. I'm a duck. Home: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html">[EMAIL PROTECTED]. PGP key available. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
Hi, > huh? NetBSD (at least) allows non-root mounts (forced to > nodev,nosuid, ..) if the user owns the mount point and has appropriate > access to the underlying device.. > > I thought that was a 4.4Lite feature.. BTW, since non-root users can mount anything, we should make the filesystems' code more robust, so that one cannot take the machine down by inserting random media and mounting it. Ciao, Wolfgang -- w...@tools.de (Wolfgang Solfrank, TooLs GmbH) +49-228-985800 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
Hi, > huh? NetBSD (at least) allows non-root mounts (forced to > nodev,nosuid, ..) if the user owns the mount point and has appropriate > access to the underlying device.. > > I thought that was a 4.4Lite feature.. BTW, since non-root users can mount anything, we should make the filesystems' code more robust, so that one cannot take the machine down by inserting random media and mounting it. Ciao, Wolfgang -- [EMAIL PROTECTED] (Wolfgang Solfrank, TooLs GmbH) +49-228-985800 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
"Ronald G. Minnich" wrote: > > the only portable user ids are names as strings. you can kludge and kludge > but at some point the kludges will pile up too high, fall over, and hurt > somebody. how many new options did we see proposed in the last 12 hours > for this problem? Actually, I think that's a kludge too. I'd rather go for encrypted data with a signature based on a public/private key algorithm, having the signature stand for "user id". But then, I have trouble going half way when it comes down to security. -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org - Can I speak to your superior? - There's some religious debate on that question. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
"Ronald G. Minnich" wrote: > > the only portable user ids are names as strings. you can kludge and kludge > but at some point the kludges will pile up too high, fall over, and hurt > somebody. how many new options did we see proposed in the last 12 hours > for this problem? Actually, I think that's a kludge too. I'd rather go for encrypted data with a signature based on a public/private key algorithm, having the signature stand for "user id". But then, I have trouble going half way when it comes down to security. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] - Can I speak to your superior? - There's some religious debate on that question. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
On Wed, 18 Aug 1999, Chris Dillon wrote: > I'm probably being extremely naive myself, but I just envisioned a > scenario like this (pardon me if someone else has already suggested > this): > > When a filesystem is mounted as foreign (HOW that is determined I > won't talk about), every file in the filesytem has its credentials > mapped to that of the mountpoint. File mode bits are not remapped in > any way. New files gain the credentials of their _foreign_ parent. > > That's the skinny. Now I'll give a (much longer) example to clarify. Sounds fine, except I'd have the owner & group passed in in the initial mount, rather than taken from "the mount point". :-) Take care, Bill To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
On Wed, 18 Aug 1999, Bill Studenmund wrote: > On Tue, 17 Aug 1999, Brian C. Grayson wrote: > > > On Tue, Aug 17, 1999 at 07:17:45PM -0700, Wilfredo Sanchez wrote: > > > A group of us at Apple are trying to figure out how to handle > > > situations where a filesystem with "foreign" user ID's are present. > > > > Have you looked at mount_umap(8)? I (naively) think it would > > solve most of your concerns. > > I don't think so. umap is for translating credentials between domains. I > think what Fred wants to do is different, and that is to ignore the > credentials on the system. > > Fred, right now what happens in MacOS when I take a disk which has sharing > credentials set up, and hook it into another machine? How are the > credentials handled there? > > Also, one of the problems which has been brought up in the thread is that > umap needs to know what credentials to translate to. For that, we'd need > to stash the credentails on the drive. I'm probably being extremely naive myself, but I just envisioned a scenario like this (pardon me if someone else has already suggested this): When a filesystem is mounted as foreign (HOW that is determined I won't talk about), every file in the filesytem has its credentials mapped to that of the mountpoint. File mode bits are not remapped in any way. New files gain the credentials of their _foreign_ parent. That's the skinny. Now I'll give a (much longer) example to clarify. An origin filesystem (created by and mounted on the same system) which happens to have stuff owned by several different users (this is all pseudo... don't mind sizes, dates, and link counts in this example): drwxr-xr-x 4 root wheel512 Aug 18 15:42 ./ drwxr-x--- 4 harry users512 Mar 10 10:21 dir1/ drwxr-xr-x 2 john users512 Jul 1 18:40 dir2/ ls -la dir1 -rw-r- 1 harry users0 Aug 18 15:48 bar -rw-r- 1 harry users0 Aug 18 15:48 foo Take this filesystem and mount it as a "foreign" filesystem on another machine. User 'jake' owns the mountpoint on the machine. drwxr-xr-x 2 jake users512 Jan 4 1999 /mnt/ mount_foreign /dev/whatever /mnt ls -la /mnt drwxr-xr-x 4 jake users512 Aug 18 15:42 ./ drwxr-x--- 4 jake users512 Mar 10 10:21 dir1/ drwxr-xr-x 2 jake users512 Jul 1 18:40 dir2/ ls -la /mnt/dir1/ -rw-r- 1 jake users0 Aug 18 15:48 bar -rw-r- 1 jake users0 Aug 18 15:48 foo Note file mode bits were not affected, but everything gained the user/group of the mountpoint. Now what happens if user 'jake' adds something to the filesystem? touch /mnt/dir1/baz ls -la /mnt/dir1/ -rw-r- 1 jake users0 Aug 18 15:48 bar -rw-r- 1 jake users0 Aug 18 15:48 foo -rw-r- 1 jake users0 Aug 18 15:50 baz
Re: Need some advice regarding portable user IDs
On Wed, 18 Aug 1999, Chris Dillon wrote: > I'm probably being extremely naive myself, but I just envisioned a > scenario like this (pardon me if someone else has already suggested > this): > > When a filesystem is mounted as foreign (HOW that is determined I > won't talk about), every file in the filesytem has its credentials > mapped to that of the mountpoint. File mode bits are not remapped in > any way. New files gain the credentials of their _foreign_ parent. > > That's the skinny. Now I'll give a (much longer) example to clarify. Sounds fine, except I'd have the owner & group passed in in the initial mount, rather than taken from "the mount point". :-) Take care, Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
On Wed, 18 Aug 1999, Wilfredo Sanchez wrote: > I think Mac OS 8 will forget about the credentials. I don't > actually know much about how sharing works. > > But the current file sharing behaviour is not entirely useful to > think about, because it doesn't effect the local permissions (much), > and the local permission are what I'm worried about. Exported > filesystems are another story, and I don't want to compilcate things > too much by worrying about that right now. My thought here was more that this was the closest thing to prior art that MacOS has, and that that might be a good user experience to emulate. ;-) Probably the thing to do is either have options to the mount call which have the mounting user own everything, or to set up a umap which maps the desired user to root for access on the filesystem. Take care, Bill To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
Wilfredo Sanchez wrote: > > A group of us at Apple are trying to figure out how to handle > situations where a filesystem with "foreign" user ID's are present. > The basic problem is that the user experience using Unix semantics > are not really pleasant. I think some examples would help: > > I'm working with Joe on a project, and I have some sources I want > him to take a look at, so I mount a floppy disk. Well, that's a bad > example, because floppies are "out"... So I mount a zip disk with UFS > on it, and I copy my source tree onto it, and hand this to Joe. Joe > takes the disk home, and sticks it in his computer, and he finds > that he can't read the files, because I have a lamer umask, and as a > bonus, I don't have an account on his machine, so the files are owned > by some random UID. Having run into this problem myself, both with tar'ed archives and zip disks I came up with the following dream world one day. In my world there are two magic uid's, one for a "read only" user and one for a "read write" user. If I give Joe a zip disk with my files on it all owned by my uid, by default when he puts it in his drive at his workstation it comes up with all files owned by the read only user. He can read the files, copy them to his work station, etc. but he can't make changes to the existing files. If I want to let Joe change the files on my disk I can set the rw flag, so when he pops it in his drive it comes up owned by the "read write" user. (Still assuming that Joe and I have mismatched uid's.) In a system like this I'd also like to see a flag that lets the owner require that the uid semantics are enforced. Also, the flags should be settable on the file, directory and disk levels. Finally in an ultra-paranoid environment you could set an option that requires that the uid matchup is for the actual person, similar to the way an ssh public key/private key pair works. Hope this is useful, Doug To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
| Fred, right now what happens in MacOS when I take a disk which has sharing | credentials set up, and hook it into another machine? How are the | credentials handled there? I think Mac OS 8 will forget about the credentials. I don't actually know much about how sharing works. But the current file sharing behaviour is not entirely useful to think about, because it doesn't effect the local permissions (much), and the local permission are what I'm worried about. Exported filesystems are another story, and I don't want to compilcate things too much by worrying about that right now. -Fred -- Wilfredo Sanchez, wsanc...@apple.com Apple Computer, Inc., Core Operating Systems / BSD Technical Lead, Darwin Project 1 Infinite Loop, 302-4K, Cupertino, CA 95014 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
On Wed, 18 Aug 1999, Bill Studenmund wrote: > On Tue, 17 Aug 1999, Brian C. Grayson wrote: > > > On Tue, Aug 17, 1999 at 07:17:45PM -0700, Wilfredo Sanchez wrote: > > > A group of us at Apple are trying to figure out how to handle > > > situations where a filesystem with "foreign" user ID's are present. > > > > Have you looked at mount_umap(8)? I (naively) think it would > > solve most of your concerns. > > I don't think so. umap is for translating credentials between domains. I > think what Fred wants to do is different, and that is to ignore the > credentials on the system. > > Fred, right now what happens in MacOS when I take a disk which has sharing > credentials set up, and hook it into another machine? How are the > credentials handled there? > > Also, one of the problems which has been brought up in the thread is that > umap needs to know what credentials to translate to. For that, we'd need > to stash the credentails on the drive. I'm probably being extremely naive myself, but I just envisioned a scenario like this (pardon me if someone else has already suggested this): When a filesystem is mounted as foreign (HOW that is determined I won't talk about), every file in the filesytem has its credentials mapped to that of the mountpoint. File mode bits are not remapped in any way. New files gain the credentials of their _foreign_ parent. That's the skinny. Now I'll give a (much longer) example to clarify. An origin filesystem (created by and mounted on the same system) which happens to have stuff owned by several different users (this is all pseudo... don't mind sizes, dates, and link counts in this example): drwxr-xr-x 4 root wheel512 Aug 18 15:42 ./ drwxr-x--- 4 harry users512 Mar 10 10:21 dir1/ drwxr-xr-x 2 john users512 Jul 1 18:40 dir2/ ls -la dir1 -rw-r- 1 harry users0 Aug 18 15:48 bar -rw-r- 1 harry users0 Aug 18 15:48 foo Take this filesystem and mount it as a "foreign" filesystem on another machine. User 'jake' owns the mountpoint on the machine. drwxr-xr-x 2 jake users512 Jan 4 1999 /mnt/ mount_foreign /dev/whatever /mnt ls -la /mnt drwxr-xr-x 4 jake users512 Aug 18 15:42 ./ drwxr-x--- 4 jake users512 Mar 10 10:21 dir1/ drwxr-xr-x 2 jake users512 Jul 1 18:40 dir2/ ls -la /mnt/dir1/ -rw-r- 1 jake users0 Aug 18 15:48 bar -rw-r- 1 jake users0 Aug 18 15:48 foo Note file mode bits were not affected, but everything gained the user/group of the mountpoint. Now what happens if user 'jake' adds something to the filesystem? touch /mnt/dir1/baz ls -la /mnt/dir1/ -rw-r- 1 jake users0 Aug 18 15:48 bar -rw-r- 1 jake users0 Aug 18 15:48 foo -rw-r- 1 jake users0 Aug 18 15:50 baz >From jake's perspective, this happens as if it were an origin filesystem and he owned everything on it. Now, mount the filesystem again on it's origin system. drwxr-xr-x 4 root wheel512 Aug 18 15:42 ./ drwxr-x--- 4 harry users512 Mar 10 10:21 dir1/ drwxr-xr-x 2 john users512 Jul 1 18:40 dir2/ Nothing changed here as far as credentials are concerned. ls -la dir1 -rw-r- 1 harry users0 Aug 18 15:48 bar -rw-r- 1 harry users0 Aug 18 15:48 foo -rw-r- 1 harry users0 Aug 18 15:50 baz The new file added by the foreign user inherited the credentials of its origin parent, just as it would have normally. Points to ponder: 1) When writing to a foreign filesystem, should file mode bits be inherited from the parent, or be based on the umask of the foreign user writing the file at that time? Can the umask of the foreign owner be preserved (which isn't necessarily the same thing as inheriting from the parent) and used? 2) How should chown and chgrp act when attempting to modify credentials on one of these foreign filesystems? Should it affect only the local credential mapping (temporarily) and not modify the foreign filesystem? Should you completely ignore the attempts and not do anything? I vote for temporarily changing credentials (until unmounted), but that is certainly a lot harder to implement than just ignoring the changes. :-) 3) What happens if you want to mount the filesystem on a machine besides the origin, but you do NOT want to do credential mapping (i.e. the systems both have the same sets of users)? This wouldn't matter if you just used a mount option or different filesystem type when mounting, but I'm assuming something automagic is wanted here. 4) What happens if you change the credentials of the mountpoint after you have mounted the foreign filesystem? Should the mappings follow the new credentials, or stay as they were when first mounted? Even if I have no idea what I'm talking about and this was the stupidest idea anyone has ever heard of, I hope that I at least sparked off a few new thought processes and got some more ideas flowing. :-) -- Chris Dillon - [EMAIL PROTE
Re: RE: Need some advice regarding portable user IDs
On Wed, 18 Aug 1999, Anthony Kimball wrote: > > : And what happens accross NIS domains? > > UID = SSN? Oops -- it's too late for RFC 666. Besides, that's Bill, not > Steve. > ROTFLMFAO (rolling on the floor laughing my f***ing a** off) ;^) Thanks for brightening my day with this grin inducing line. - Todd To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: RE: Need some advice regarding portable user IDs
: And what happens accross NIS domains? UID = SSN? Oops -- it's too late for RFC 666. Besides, that's Bill, not Steve. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
On Wed, 18 Aug 1999, Wilfredo Sanchez wrote: > I think Mac OS 8 will forget about the credentials. I don't > actually know much about how sharing works. > > But the current file sharing behaviour is not entirely useful to > think about, because it doesn't effect the local permissions (much), > and the local permission are what I'm worried about. Exported > filesystems are another story, and I don't want to compilcate things > too much by worrying about that right now. My thought here was more that this was the closest thing to prior art that MacOS has, and that that might be a good user experience to emulate. ;-) Probably the thing to do is either have options to the mount call which have the mounting user own everything, or to set up a umap which maps the desired user to root for access on the filesystem. Take care, Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
Wilfredo Sanchez wrote: > > A group of us at Apple are trying to figure out how to handle > situations where a filesystem with "foreign" user ID's are present. > The basic problem is that the user experience using Unix semantics > are not really pleasant. I think some examples would help: > > I'm working with Joe on a project, and I have some sources I want > him to take a look at, so I mount a floppy disk. Well, that's a bad > example, because floppies are "out"... So I mount a zip disk with UFS > on it, and I copy my source tree onto it, and hand this to Joe. Joe > takes the disk home, and sticks it in his computer, and he finds > that he can't read the files, because I have a lamer umask, and as a > bonus, I don't have an account on his machine, so the files are owned > by some random UID. Having run into this problem myself, both with tar'ed archives and zip disks I came up with the following dream world one day. In my world there are two magic uid's, one for a "read only" user and one for a "read write" user. If I give Joe a zip disk with my files on it all owned by my uid, by default when he puts it in his drive at his workstation it comes up with all files owned by the read only user. He can read the files, copy them to his work station, etc. but he can't make changes to the existing files. If I want to let Joe change the files on my disk I can set the rw flag, so when he pops it in his drive it comes up owned by the "read write" user. (Still assuming that Joe and I have mismatched uid's.) In a system like this I'd also like to see a flag that lets the owner require that the uid semantics are enforced. Also, the flags should be settable on the file, directory and disk levels. Finally in an ultra-paranoid environment you could set an option that requires that the uid matchup is for the actual person, similar to the way an ssh public key/private key pair works. Hope this is useful, Doug To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
| Fred, right now what happens in MacOS when I take a disk which has sharing | credentials set up, and hook it into another machine? How are the | credentials handled there? I think Mac OS 8 will forget about the credentials. I don't actually know much about how sharing works. But the current file sharing behaviour is not entirely useful to think about, because it doesn't effect the local permissions (much), and the local permission are what I'm worried about. Exported filesystems are another story, and I don't want to compilcate things too much by worrying about that right now. -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: RE: Need some advice regarding portable user IDs
On Wed, 18 Aug 1999, Anthony Kimball wrote: > > : And what happens accross NIS domains? > > UID = SSN? Oops -- it's too late for RFC 666. Besides, that's Bill, not > Steve. > ROTFLMFAO (rolling on the floor laughing my f***ing a** off) ;^) Thanks for brightening my day with this grin inducing line. - Todd To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
On Tue, 17 Aug 1999, Brian C. Grayson wrote: > On Tue, Aug 17, 1999 at 07:17:45PM -0700, Wilfredo Sanchez wrote: > > A group of us at Apple are trying to figure out how to handle > > situations where a filesystem with "foreign" user ID's are present. > > Have you looked at mount_umap(8)? I (naively) think it would > solve most of your concerns. I don't think so. umap is for translating credentials between domains. I think what Fred wants to do is different, and that is to ignore the credentials on the system. Fred, right now what happens in MacOS when I take a disk which has sharing credentials set up, and hook it into another machine? How are the credentials handled there? Also, one of the problems which has been brought up in the thread is that umap needs to know what credentials to translate to. For that, we'd need to stash the credentails on the drive. Take care, Bill To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: RE: Need some advice regarding portable user IDs
: And what happens accross NIS domains? UID = SSN? Oops -- it's too late for RFC 666. Besides, that's Bill, not Steve. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
On Wed, 18 Aug 1999, Marc Ramirez wrote: > Oh! I was under the impression that it just didn't work, even with > correct perms, but I use FreeBSD. Lemme try it... Can't mount, even > with 0666 on /dev/fd0. Maybe I'm being stupid. Wouldn't be the first > time! It's controlled by a sysctl in FreeBSD which defaults to "off" - I forget what it is called. Kris To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
On Tue, 17 Aug 1999, Brian C. Grayson wrote: > On Tue, Aug 17, 1999 at 07:17:45PM -0700, Wilfredo Sanchez wrote: > > A group of us at Apple are trying to figure out how to handle > > situations where a filesystem with "foreign" user ID's are present. > > Have you looked at mount_umap(8)? I (naively) think it would > solve most of your concerns. I don't think so. umap is for translating credentials between domains. I think what Fred wants to do is different, and that is to ignore the credentials on the system. Fred, right now what happens in MacOS when I take a disk which has sharing credentials set up, and hook it into another machine? How are the credentials handled there? Also, one of the problems which has been brought up in the thread is that umap needs to know what credentials to translate to. For that, we'd need to stash the credentails on the drive. Take care, Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
On Wed, 18 Aug 1999, Marc Ramirez wrote: > Oh! I was under the impression that it just didn't work, even with > correct perms, but I use FreeBSD. Lemme try it... Can't mount, even > with 0666 on /dev/fd0. Maybe I'm being stupid. Wouldn't be the first > time! It's controlled by a sysctl in FreeBSD which defaults to "off" - I forget what it is called. Kris To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: RE: Need some advice regarding portable user IDs
| > when new media is available and it will try to mount it. The present | > behaviour in Mac OS X Server is that everything mounted this way is | > trusted, though the Finder should be requesting nosetuid; I should | > check that. It's also possible that the kernel will number drives in | > a different order (eg. /dev/sd0a this boot might be /dev/sd1a next | > boot), particularly if you are shuffling drives around. (Remember | > that hot-swap complicates this.) So a string like "/dev/sd0a" in | > fstab is fragile, and it works out better if we keep that information | > on the mounted media rather than on the root volume. | | What happens with conflicting names? Append "_1", "_2", etc. -Fred -- Wilfredo Sanchez, wsanc...@apple.com Apple Computer, Inc., Core Operating Systems / BSD Technical Lead, Darwin Project 1 Infinite Loop, 302-4K, Cupertino, CA 95014 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: RE: Need some advice regarding portable user IDs
| > when new media is available and it will try to mount it. The present | > behaviour in Mac OS X Server is that everything mounted this way is | > trusted, though the Finder should be requesting nosetuid; I should | > check that. It's also possible that the kernel will number drives in | > a different order (eg. /dev/sd0a this boot might be /dev/sd1a next | > boot), particularly if you are shuffling drives around. (Remember | > that hot-swap complicates this.) So a string like "/dev/sd0a" in | > fstab is fragile, and it works out better if we keep that information | > on the mounted media rather than on the root volume. | | What happens with conflicting names? Append "_1", "_2", etc. -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: Need some advice regarding portable user IDs
On Wed, 18 Aug 1999, David Malone wrote: > On Wed, Aug 18, 1999 at 07:39:11AM -0400, Marc Ramirez wrote: > > Oh! I was under the impression that it just didn't work, even with > > correct perms, but I use FreeBSD. Lemme try it... Can't mount, even > > with 0666 on /dev/fd0. Maybe I'm being stupid. Wouldn't be the first > > time! > > You have to turn it on with a sysctl: "sysctl -w vfs.usermount=1" I > think. So it is. Thanks. Marc. -- Marc Ramirez - OwnerGreat Big Throbbing Brains mr...@gbtb.com http://www.gbtb.com Our brains throb, so yours won't have to! To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
the only portable user ids are names as strings. you can kludge and kludge but at some point the kludges will pile up too high, fall over, and hurt somebody. how many new options did we see proposed in the last 12 hours for this problem? ron To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
On Wed, 18 Aug 1999, David Malone wrote: > On Wed, Aug 18, 1999 at 07:39:11AM -0400, Marc Ramirez wrote: > > Oh! I was under the impression that it just didn't work, even with > > correct perms, but I use FreeBSD. Lemme try it... Can't mount, even > > with 0666 on /dev/fd0. Maybe I'm being stupid. Wouldn't be the first > > time! > > You have to turn it on with a sysctl: "sysctl -w vfs.usermount=1" I > think. So it is. Thanks. Marc. -- Marc Ramirez - OwnerGreat Big Throbbing Brains [EMAIL PROTECTED] http://www.gbtb.com Our brains throb, so yours won't have to! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
the only portable user ids are names as strings. you can kludge and kludge but at some point the kludges will pile up too high, fall over, and hurt somebody. how many new options did we see proposed in the last 12 hours for this problem? ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
> "Wilfredo" == Wilfredo Sanchez writes: Wilfredo> I think the desired behaviour would be that since this is Wilfredo> effectively now Joe's zip disk, he should be able to do as he Wilfredo> pleases. One proposal might be to give the console user the Wilfredo> equivalent of root's priveledges on any removeable media he inserts Right now, with MSDOS floppies, with no userids, the user owning the mount point gets his userid applied to the entire disk. This allows me to mount my floppies, etc. on mount points that I own, and I own all the resulting files. I think you want the same thing as an option for UFS mounts. Wilfredo> Presumably the console user is the one fiddling with the external Wilfredo> media. I don't think this is entirely true, and isn't a useful or enforceable restriction. Wilfredo> As another example, a similar situation often comes up on the net Wilfredo> with tar files containing UIDs and GIDs other than zero. Only with SYSV chown semantics that allow non-root to make files not owned by them. Wilfredo> So perhaps there needs to be a way to mark a drive as local Wilfredo> (perhaps with a host ID of some sort?) and noticing when a volume is Wilfredo> "foreign" that you need to do something special. Certainly you might Wilfredo> want to ignore setuid bits, for starters. This could simply be Wilfredo> something like fstab, which lists the local drives, and everything Wilfredo> else isn't considered local. This is solved by having the "nouid" or somesuch thing add to /etc/fstab by the admin who knows which ones should be trusted. Linux provides "user" to get the behaviour that we get for free. Wilfredo> Has anyone dived into this area already and have some experience Wilfredo> with it? It's confusing me pretty good. See what AT&T did with RFS. This may be a negative example (i.e. don't do this). :!mcr!:| Cow#1: Are you worried about getting Mad Cow Disease? Michael Richardson | Cow#2: No. I'm a duck. Home: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html";>m...@sandelman.ottawa.on.ca. PGP key available. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
> "Wilfredo" == Wilfredo Sanchez <[EMAIL PROTECTED]> writes: Wilfredo> I think the desired behaviour would be that since this is Wilfredo> effectively now Joe's zip disk, he should be able to do as he Wilfredo> pleases. One proposal might be to give the console user the Wilfredo> equivalent of root's priveledges on any removeable media he inserts Right now, with MSDOS floppies, with no userids, the user owning the mount point gets his userid applied to the entire disk. This allows me to mount my floppies, etc. on mount points that I own, and I own all the resulting files. I think you want the same thing as an option for UFS mounts. Wilfredo> Presumably the console user is the one fiddling with the external Wilfredo> media. I don't think this is entirely true, and isn't a useful or enforceable restriction. Wilfredo> As another example, a similar situation often comes up on the net Wilfredo> with tar files containing UIDs and GIDs other than zero. Only with SYSV chown semantics that allow non-root to make files not owned by them. Wilfredo> So perhaps there needs to be a way to mark a drive as local Wilfredo> (perhaps with a host ID of some sort?) and noticing when a volume is Wilfredo> "foreign" that you need to do something special. Certainly you might Wilfredo> want to ignore setuid bits, for starters. This could simply be Wilfredo> something like fstab, which lists the local drives, and everything Wilfredo> else isn't considered local. This is solved by having the "nouid" or somesuch thing add to /etc/fstab by the admin who knows which ones should be trusted. Linux provides "user" to get the behaviour that we get for free. Wilfredo> Has anyone dived into this area already and have some experience Wilfredo> with it? It's confusing me pretty good. See what AT&T did with RFS. This may be a negative example (i.e. don't do this). :!mcr!:| Cow#1: Are you worried about getting Mad Cow Disease? Michael Richardson | Cow#2: No. I'm a duck. Home: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html">[EMAIL PROTECTED]. PGP key available. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
Hi, > huh? NetBSD (at least) allows non-root mounts (forced to > nodev,nosuid, ..) if the user owns the mount point and has appropriate > access to the underlying device.. > > I thought that was a 4.4Lite feature.. Yes, it was part of 4.4Lite2. And I still have the discussion from 1994 between Chris Demetriou, Kirk McKusick and myself which triggered this feature. (For the record, (the equivalent of) c...@netbsd.org was CC'ed on this discussion, and Theo kicked in later, too). Back then, I was arguing to use the mounter's uid, if it wasn't root, as owner for all files (well, we were discussing this more or less with respect to msdosfs only, so you have to set some uid as the owner of files anyway), but Chris was arguing that the man in front of the box should be able to mount some floppy for some other guy and give him access to his files. Actually substituting the mounter for the owner of the files should be quite easy to implement (since most filesystems now use the generic vaccess routine for access checking, it wouldn't even require changes to most filesystems), as the mounter is available in the mount structure anyway. (It is checked on an unmount, so only the mounter (and root, of course) can unmount a filesystem). However, if we'd make it an option to the generic mount code, it would probably be a good idea to make the substitution uid and gid extra arguments to the mount command for the reasons Chris mentioned back then. Ciao, Wolfgang PS: BTW, shouldn't this be on tech-k...@netbsd.org instead of tech-userlevel? -- w...@tools.de (Wolfgang Solfrank, TooLs GmbH) +49-228-985800 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
On 18 Aug, Marc Ramirez wrote: > Oh! I was under the impression that it just didn't work, even with > correct perms, but I use FreeBSD. Lemme try it... Can't mount, even > with 0666 on /dev/fd0. Maybe I'm being stupid. Wouldn't be the first > time! > > Marc. No miracle, the mount command has uid 0 hardcoded in the source where you are checked if you are allowed to use the mount command. I've been thinking of a neat way to re-organize that code myself for some time now, and thought I had come up with a solution (It's the reason I subscribed to this list in the first place). With the current discussion, I figure it has some major shortcomings. It adds some things too, though, like the permissions to audio devices, etc. Anyway, I wrote a "paper" about it that I can post here if anybody is interested. In that case, which format s liked best: plain text, TeX or postscript? I assume the first. -- Alban Hertroys. http://wit401310.student.utwente.nl == If there is a here-after, then there are much more people dead than alive. Even that much more that the number of living people is insignificant in comparison to the dead ones. Thus it is safe to say that we don't exist. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
On Wed, Aug 18, 1999 at 07:39:11AM -0400, Marc Ramirez wrote: > Oh! I was under the impression that it just didn't work, even with > correct perms, but I use FreeBSD. Lemme try it... Can't mount, even > with 0666 on /dev/fd0. Maybe I'm being stupid. Wouldn't be the first > time! You have to turn it on with a sysctl: "sysctl -w vfs.usermount=1" I think. David. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
[ CC's trimmed ] On Wed, 18 Aug 1999, Bill Sommerfeld wrote: > > Yeah. That's definitely where I'd start from. I think the main obstacle > > for any *BSD system in the ease-of-use department will be the > > must-mount-as-root issue. > > huh? NetBSD (at least) allows non-root mounts (forced to > nodev,nosuid, ..) if the user owns the mount point and has appropriate > access to the underlying device.. Oh! I was under the impression that it just didn't work, even with correct perms, but I use FreeBSD. Lemme try it... Can't mount, even with 0666 on /dev/fd0. Maybe I'm being stupid. Wouldn't be the first time! Marc. > I thought that was a 4.4Lite feature.. > > - Bill -- Marc Ramirez - OwnerGreat Big Throbbing Brains mr...@gbtb.com http://www.gbtb.com Our brains throb, so yours won't have to! To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
I had a thought on this It seems you are trying to provide the "floppy model" that users currently have with their PCs. User A writes the floppy, User B can read it and do whatever he wants... (I know this is Apple - but I'll stick to MSDOS for the discussion, and "floppy" indicates any removable media.) The reason for this is that MSDOS filesystems don't keep any user credentials. So, use B can read anything on any floppy he can find. Wouldn't creating a file system that didn't support user credentials solve your problem? Format the floppy in that file system and hand it to user B. When user B mounts it, he can do whatever he wants. User A is aware of how the floppy was created, as presumably some special step is required to create the "discard credential" file system on the floppy. Perhaps, such a file system could even be a UFS with a special marker somewhere? Then, this marker could be "twiddled" after the fact. For example, user A formats and makes a new UFS file system on the floppy, and copies the files over. Marks it as having no credentials (twiddles the bit) and hands it to user B. User B mounts it, with a regular UFS mount - but because the magic bit is "twiddled" GID and UID are ??? (here's where things break down, just what do you use for those? root/nobody/user's gid&uid?) Just some thoughts... - Dave Rivers - To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
Hi, > huh? NetBSD (at least) allows non-root mounts (forced to > nodev,nosuid, ..) if the user owns the mount point and has appropriate > access to the underlying device.. > > I thought that was a 4.4Lite feature.. Yes, it was part of 4.4Lite2. And I still have the discussion from 1994 between Chris Demetriou, Kirk McKusick and myself which triggered this feature. (For the record, (the equivalent of) [EMAIL PROTECTED] was CC'ed on this discussion, and Theo kicked in later, too). Back then, I was arguing to use the mounter's uid, if it wasn't root, as owner for all files (well, we were discussing this more or less with respect to msdosfs only, so you have to set some uid as the owner of files anyway), but Chris was arguing that the man in front of the box should be able to mount some floppy for some other guy and give him access to his files. Actually substituting the mounter for the owner of the files should be quite easy to implement (since most filesystems now use the generic vaccess routine for access checking, it wouldn't even require changes to most filesystems), as the mounter is available in the mount structure anyway. (It is checked on an unmount, so only the mounter (and root, of course) can unmount a filesystem). However, if we'd make it an option to the generic mount code, it would probably be a good idea to make the substitution uid and gid extra arguments to the mount command for the reasons Chris mentioned back then. Ciao, Wolfgang PS: BTW, shouldn't this be on [EMAIL PROTECTED] instead of tech-userlevel? -- [EMAIL PROTECTED] (Wolfgang Solfrank, TooLs GmbH) +49-228-985800 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
> Yeah. That's definitely where I'd start from. I think the main obstacle > for any *BSD system in the ease-of-use department will be the > must-mount-as-root issue. huh? NetBSD (at least) allows non-root mounts (forced to nodev,nosuid, ..) if the user owns the mount point and has appropriate access to the underlying device.. I thought that was a 4.4Lite feature.. - Bill To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
On 18 Aug, Marc Ramirez wrote: > Oh! I was under the impression that it just didn't work, even with > correct perms, but I use FreeBSD. Lemme try it... Can't mount, even > with 0666 on /dev/fd0. Maybe I'm being stupid. Wouldn't be the first > time! > > Marc. No miracle, the mount command has uid 0 hardcoded in the source where you are checked if you are allowed to use the mount command. I've been thinking of a neat way to re-organize that code myself for some time now, and thought I had come up with a solution (It's the reason I subscribed to this list in the first place). With the current discussion, I figure it has some major shortcomings. It adds some things too, though, like the permissions to audio devices, etc. Anyway, I wrote a "paper" about it that I can post here if anybody is interested. In that case, which format s liked best: plain text, TeX or postscript? I assume the first. -- Alban Hertroys. http://wit401310.student.utwente.nl == If there is a here-after, then there are much more people dead than alive. Even that much more that the number of living people is insignificant in comparison to the dead ones. Thus it is safe to say that we don't exist. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
On Wed, Aug 18, 1999 at 07:39:11AM -0400, Marc Ramirez wrote: > Oh! I was under the impression that it just didn't work, even with > correct perms, but I use FreeBSD. Lemme try it... Can't mount, even > with 0666 on /dev/fd0. Maybe I'm being stupid. Wouldn't be the first > time! You have to turn it on with a sysctl: "sysctl -w vfs.usermount=1" I think. David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
[ CC's trimmed ] On Wed, 18 Aug 1999, Bill Sommerfeld wrote: > > Yeah. That's definitely where I'd start from. I think the main obstacle > > for any *BSD system in the ease-of-use department will be the > > must-mount-as-root issue. > > huh? NetBSD (at least) allows non-root mounts (forced to > nodev,nosuid, ..) if the user owns the mount point and has appropriate > access to the underlying device.. Oh! I was under the impression that it just didn't work, even with correct perms, but I use FreeBSD. Lemme try it... Can't mount, even with 0666 on /dev/fd0. Maybe I'm being stupid. Wouldn't be the first time! Marc. > I thought that was a 4.4Lite feature.. > > - Bill -- Marc Ramirez - OwnerGreat Big Throbbing Brains [EMAIL PROTECTED] http://www.gbtb.com Our brains throb, so yours won't have to! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
I had a thought on this It seems you are trying to provide the "floppy model" that users currently have with their PCs. User A writes the floppy, User B can read it and do whatever he wants... (I know this is Apple - but I'll stick to MSDOS for the discussion, and "floppy" indicates any removable media.) The reason for this is that MSDOS filesystems don't keep any user credentials. So, use B can read anything on any floppy he can find. Wouldn't creating a file system that didn't support user credentials solve your problem? Format the floppy in that file system and hand it to user B. When user B mounts it, he can do whatever he wants. User A is aware of how the floppy was created, as presumably some special step is required to create the "discard credential" file system on the floppy. Perhaps, such a file system could even be a UFS with a special marker somewhere? Then, this marker could be "twiddled" after the fact. For example, user A formats and makes a new UFS file system on the floppy, and copies the files over. Marks it as having no credentials (twiddles the bit) and hands it to user B. User B mounts it, with a regular UFS mount - but because the magic bit is "twiddled" GID and UID are ??? (here's where things break down, just what do you use for those? root/nobody/user's gid&uid?) Just some thoughts... - Dave Rivers - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
On Wed, 18 Aug 1999, Ignatios Souvatzis wrote: > On Wed, Aug 18, 1999 at 05:00:48AM -0400, Marc Ramirez wrote: > > > > I was thinking about this the other day, while mousting a series of floppy > > disks, and it seems to me that what you're looking for, at least for > > removable media, is a sort of single-user UFS that says "Joe Schmoe owns > > this file system." > > our(*) msdos and ados filesystems (at least) do (sort of) this. Yeah. That's definitely where I'd start from. I think the main obstacle for any *BSD system in the ease-of-use department will be the must-mount-as-root issue. I don't know what's involved in getting that to work properly. Maybe the best solution is to have some sort of automount daemon. That would more than likely work for devices with media detection (Mac floppys come to mind... :) The devil's in the details... Marc. > Regards, > -is > > *) where we = NetBSD > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-hackers" in the body of the message > -- Marc Ramirez - OwnerGreat Big Throbbing Brains mr...@gbtb.com http://www.gbtb.com Our brains throb, so yours won't have to! To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
> Yeah. That's definitely where I'd start from. I think the main obstacle > for any *BSD system in the ease-of-use department will be the > must-mount-as-root issue. huh? NetBSD (at least) allows non-root mounts (forced to nodev,nosuid, ..) if the user owns the mount point and has appropriate access to the underlying device.. I thought that was a 4.4Lite feature.. - Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
On Wed, Aug 18, 1999 at 05:00:48AM -0400, Marc Ramirez wrote: > > I was thinking about this the other day, while mousting a series of floppy > disks, and it seems to me that what you're looking for, at least for > removable media, is a sort of single-user UFS that says "Joe Schmoe owns > this file system." our(*) msdos and ados filesystems (at least) do (sort of) this. Regards, -is *) where we = NetBSD To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
On Tue, 17 Aug 1999, Wilfredo Sanchez wrote:
> A group of us at Apple are trying to figure out how to handle
> situations where a filesystem with "foreign" user ID's are present.
[...]
> that he can't read the files, because I have a lamer umask, and as a
> bonus, I don't have an account on his machine, so the files are owned
> by some random UID.
[...]
> effectively now Joe's zip disk, he should be able to do as he
> pleases. One proposal might be to give the console user the
> equivalent of root's priveledges on any removeable media he inserts
> into the machine while he's logged in on the console. This solves
[...]
> implications aside for the moment), is that knowing what media is
> removeable is becoming increasingly difficult. Hot-swappable drives
[...]
> So perhaps there needs to be a way to mark a drive as local
> (perhaps with a host ID of some sort?) and noticing when a volume is
> "foreign" that you need to do something special. Certainly you might
[...]
This has been tackled by folks distributing via ISO9660+RockRidge.. It's
based on a few assumptions:
1) It's data specifically tagged for export.
2) If you're giving it to Other Guy, you obviously want him to be able to
read it and navigate it without impediment (otherwise, you wouldn't
have put it on there, would you?)
3) Other Guy is responsible for managing his new files.
So, let's remove the ROM mentality and apply it to our "removable" media
problem:
1) The data may or may not be specifically tagged export.
With a ROM, you only decide once what this child of your creativity's
purpose will be in life. Is it staying home or going abroad?
It would be safe to assume that a very solid majority of users will be
neither familiar with mastering nor happy with having the inflexibility of
being forced to decide at "Erase Disk..." time (who changed it to that
anyway? :P ) whether this volume is local or exported.
2) You'll still want Other Guy to be able to navigate without impediment.
The default action would be to save ownership/permission information on
media for local use and present a least common denominator view (chown -R
0.0 && chmod -R a=rX) for other recipients. It ought to be transparent,
but otherwise able to be manually fiddled with (sometimes you just don't
want other people to be able to find out your uname is "fuckwit1").
So yeah, you'll want to tag your media as MINE. A superhappyfun-hash of
the hostname and something else ought to make a nice tag.
So far as where to put it depends on the FS. Take a looksee at
RockRidge's RRIP and SUSP at:
ftp://ftp.ymi.com/pub/rockridge/
Or be slicker with UDF at:
http://www.osta.org/html/ostatech.html#udf
3) Other guy is still responsible for managing his new files.
This can and will get oftly interesting oftly quickly.
a) Other Guy goes to mount the media the originator gave him. He checks
the superhappyfun-hash ID, which doesn't match his system. The disk is
considered alien and goes to LCD mode. One could blindly assume that if
Other Guy was able to mount the media (not necessarily be at console) that
he ought to own everything on it. Reasonable.
b) Other Guy (optionally) has his machine try a little harder to figure
out what's actually going on. It could look at the ownership/permissions
on the media itself, get a feel for what's what and where, then try to
construct a filesystem utopia. This can, in and of itself, get oftly
intersting oftly quickly.
c) Other Guy (optionally) tweaks things himself.
d) From there? He could designate himself the new originator of the media
by relabeling the source ID to 'OGsuperhappyfun-hash'. Or, he could store
his own o/p map .. locally or maybe on the media itself? He could also
remaster the media ("fuckwit2")..
Ohh, what a tangled web we do weave ... :)
Personally, I like the redesignation.. This could get very expensive,
though, for large volumes and/or frequent system swaps (remap, move,
remap, move, remap, move, remap.)
> As another example, a similar situation often comes up on the net
> with tar files containing UIDs and GIDs other than zero.
No it doesn't. If you can't chown, touch, or chmod the extracted file to
match the archived state, you won't. It's yours with your umask.
___ ___ . . ___
\/ |\ |\ \
_\_ /__ |-\ |-\ \__
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
On Wed, 18 Aug 1999, Ignatios Souvatzis wrote: > On Wed, Aug 18, 1999 at 05:00:48AM -0400, Marc Ramirez wrote: > > > > I was thinking about this the other day, while mousting a series of floppy > > disks, and it seems to me that what you're looking for, at least for > > removable media, is a sort of single-user UFS that says "Joe Schmoe owns > > this file system." > > our(*) msdos and ados filesystems (at least) do (sort of) this. Yeah. That's definitely where I'd start from. I think the main obstacle for any *BSD system in the ease-of-use department will be the must-mount-as-root issue. I don't know what's involved in getting that to work properly. Maybe the best solution is to have some sort of automount daemon. That would more than likely work for devices with media detection (Mac floppys come to mind... :) The devil's in the details... Marc. > Regards, > -is > > *) where we = NetBSD > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > -- Marc Ramirez - OwnerGreat Big Throbbing Brains [EMAIL PROTECTED] http://www.gbtb.com Our brains throb, so yours won't have to! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
On Wed, Aug 18, 1999 at 05:00:48AM -0400, Marc Ramirez wrote: > > I was thinking about this the other day, while mousting a series of floppy > disks, and it seems to me that what you're looking for, at least for > removable media, is a sort of single-user UFS that says "Joe Schmoe owns > this file system." our(*) msdos and ados filesystems (at least) do (sort of) this. Regards, -is *) where we = NetBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
On Tue, 17 Aug 1999, Wilfredo Sanchez wrote: > A group of us at Apple are trying to figure out how to handle > situations where a filesystem with "foreign" user ID's are present. > The basic problem is that the user experience using Unix semantics > are not really pleasant. I think some examples would help: I was thinking about this the other day, while mousting a series of floppy disks, and it seems to me that what you're looking for, at least for removable media, is a sort of single-user UFS that says "Joe Schmoe owns this file system." Assuming that neither you nor Joe have accounts on each other's machines: 0) Non-root users should be able to mount disks. This really goes without saying for desktop systems. 1) You mount_suufs his disk with some sort of "foreign-user" option, and the system chooses an unused, per device UID and GID, and all the directories are mapped to that ownership. 2) You copy the files to a world wrx directory, and they all automagically become foreign ownership. 3) Joe goes to his computer and mounts his disk, and voila, he owns everything (it's his filesystem after all). This handles the simple case of just shuffling files around. If you wanted more elaborate collaborations, you'd really have to give each other accounts. You could monkey around with keeping passwd files and such on the medium and umapping, but you couldn't copy files from the Zip to the local FS without future-user-clash. This also affords Joe more than your normal level of security, assuming he trusts root on all the systems involved. Marc. -- Marc Ramirez - OwnerGreat Big Throbbing Brains mr...@gbtb.com http://www.gbtb.com Our brains throb, so yours won't have to! To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
On Tue, 17 Aug 1999, Wilfredo Sanchez wrote:
> A group of us at Apple are trying to figure out how to handle
> situations where a filesystem with "foreign" user ID's are present.
[...]
> that he can't read the files, because I have a lamer umask, and as a
> bonus, I don't have an account on his machine, so the files are owned
> by some random UID.
[...]
> effectively now Joe's zip disk, he should be able to do as he
> pleases. One proposal might be to give the console user the
> equivalent of root's priveledges on any removeable media he inserts
> into the machine while he's logged in on the console. This solves
[...]
> implications aside for the moment), is that knowing what media is
> removeable is becoming increasingly difficult. Hot-swappable drives
[...]
> So perhaps there needs to be a way to mark a drive as local
> (perhaps with a host ID of some sort?) and noticing when a volume is
> "foreign" that you need to do something special. Certainly you might
[...]
This has been tackled by folks distributing via ISO9660+RockRidge.. It's
based on a few assumptions:
1) It's data specifically tagged for export.
2) If you're giving it to Other Guy, you obviously want him to be able to
read it and navigate it without impediment (otherwise, you wouldn't
have put it on there, would you?)
3) Other Guy is responsible for managing his new files.
So, let's remove the ROM mentality and apply it to our "removable" media
problem:
1) The data may or may not be specifically tagged export.
With a ROM, you only decide once what this child of your creativity's
purpose will be in life. Is it staying home or going abroad?
It would be safe to assume that a very solid majority of users will be
neither familiar with mastering nor happy with having the inflexibility of
being forced to decide at "Erase Disk..." time (who changed it to that
anyway? :P ) whether this volume is local or exported.
2) You'll still want Other Guy to be able to navigate without impediment.
The default action would be to save ownership/permission information on
media for local use and present a least common denominator view (chown -R
0.0 && chmod -R a=rX) for other recipients. It ought to be transparent,
but otherwise able to be manually fiddled with (sometimes you just don't
want other people to be able to find out your uname is "fuckwit1").
So yeah, you'll want to tag your media as MINE. A superhappyfun-hash of
the hostname and something else ought to make a nice tag.
So far as where to put it depends on the FS. Take a looksee at
RockRidge's RRIP and SUSP at:
ftp://ftp.ymi.com/pub/rockridge/
Or be slicker with UDF at:
http://www.osta.org/html/ostatech.html#udf
3) Other guy is still responsible for managing his new files.
This can and will get oftly interesting oftly quickly.
a) Other Guy goes to mount the media the originator gave him. He checks
the superhappyfun-hash ID, which doesn't match his system. The disk is
considered alien and goes to LCD mode. One could blindly assume that if
Other Guy was able to mount the media (not necessarily be at console) that
he ought to own everything on it. Reasonable.
b) Other Guy (optionally) has his machine try a little harder to figure
out what's actually going on. It could look at the ownership/permissions
on the media itself, get a feel for what's what and where, then try to
construct a filesystem utopia. This can, in and of itself, get oftly
intersting oftly quickly.
c) Other Guy (optionally) tweaks things himself.
d) From there? He could designate himself the new originator of the media
by relabeling the source ID to 'OGsuperhappyfun-hash'. Or, he could store
his own o/p map .. locally or maybe on the media itself? He could also
remaster the media ("fuckwit2")..
Ohh, what a tangled web we do weave ... :)
Personally, I like the redesignation.. This could get very expensive,
though, for large volumes and/or frequent system swaps (remap, move,
remap, move, remap, move, remap.)
> As another example, a similar situation often comes up on the net
> with tar files containing UIDs and GIDs other than zero.
No it doesn't. If you can't chown, touch, or chmod the extracted file to
match the archived state, you won't. It's yours with your umask.
___ ___ . . ___
\/ |\ |\ \
_\_ /__ |-\ |-\ \__
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
On Tue, 17 Aug 1999, Wilfredo Sanchez wrote: > A group of us at Apple are trying to figure out how to handle > situations where a filesystem with "foreign" user ID's are present. > The basic problem is that the user experience using Unix semantics > are not really pleasant. I think some examples would help: I was thinking about this the other day, while mousting a series of floppy disks, and it seems to me that what you're looking for, at least for removable media, is a sort of single-user UFS that says "Joe Schmoe owns this file system." Assuming that neither you nor Joe have accounts on each other's machines: 0) Non-root users should be able to mount disks. This really goes without saying for desktop systems. 1) You mount_suufs his disk with some sort of "foreign-user" option, and the system chooses an unused, per device UID and GID, and all the directories are mapped to that ownership. 2) You copy the files to a world wrx directory, and they all automagically become foreign ownership. 3) Joe goes to his computer and mounts his disk, and voila, he owns everything (it's his filesystem after all). This handles the simple case of just shuffling files around. If you wanted more elaborate collaborations, you'd really have to give each other accounts. You could monkey around with keeping passwd files and such on the medium and umapping, but you couldn't copy files from the Zip to the local FS without future-user-clash. This also affords Joe more than your normal level of security, assuming he trusts root on all the systems involved. Marc. -- Marc Ramirez - OwnerGreat Big Throbbing Brains [EMAIL PROTECTED] http://www.gbtb.com Our brains throb, so yours won't have to! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
> A group of us at Apple are trying to figure out how to handle > situations where a filesystem with "foreign" user ID's are present. > The basic problem is that the user experience using Unix semantics > are not really pleasant. I think some examples would help: Basically, you have two alternatives; transport the user credentials with the media, or map the credentials on the media to something that's more sensible. In different situations, one or the other of these might make more sense. Throwing some examples: a) You put some files on a removable device. They are "owned" by you. You give the media to someone else, who then mounts it on their own system (which is logically totally disjoint to yours). The desired goal is for the recipient to be able to access the files just as you could. In this case, possession of the media is the desired credential, so the media itself should (ideally) not contain any other credential information (or it should be ignored). b) You move a disk from one server on your network to another. The disk contains files owned by hundreds of users. The desired goal in this case is for the users that could access the files on the first server to be able to access the same files in the same fashion when the disk is on the second server. In this case, the credentials are external to the media and need to be verified against it. One possible way of differentiating these two cases would be to have a flag associated with the media (filesystem perhaps) that indicates whether the media has "security features" enabled. If it doesn't, the media should appear as though everything on it is owned by the user that has mounted it. You would default "security features" off when removable media were initialised. With "security features" on, the media behaviour would be what we consider normal; permissions on files, directories etc. are checked and so forth. The issues related to migrating volumes with "security features" enabled are more interesting; the only atomic way to migrate the credential verification information is to write it to the disk before it's removed. eg. You would offer a "prepare disk for export" option which scanned the disk and wrote out a passwd/group-style database containing the credentials for the uids and gids represented on the volume; this would then need to be integrated into the new system in a suitable fashion, either by merging apparently identical users/groups (and possibly scanning the disk volume to update uid/gid values) into the new system's authentication databases (this would have some perhaps slightly interesting consequences), or by applying the per-volume list as a translation to allow users known to the media to access the system in some suitably limited fashion in order to get at the data on the media. One alternative that would allow migration within a heterogenous network but prevent dealing with the quite complex issues of migrating credentials would simply be to scan every volume with "security features" enabled which didn't appear to have been last used locally and check that all the users represented there were locally valid. This would benefit from having the uid:username and gid:groupname mappings available (maybe it would be faster just to dump the entire database to the disk?) since the scan could fall back to using a network authentication service (NIS, etc.) to obtain the data required to support the users locally. I'm probably being as confusing as you thought you were. Any of this any use? -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msm...@freebsd.org \\-- Joseph Merrick \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
+[ Wilfredo Sanchez ]- | A group of us at Apple are trying to figure out how to handle | situations where a filesystem with "foreign" user ID's are present. | The basic problem is that the user experience using Unix semantics | are not really pleasant. I think some examples would help: Why not simply translate unknown ids to the current user? I don't mean modifying the owners on disk. The real problem comes if a new user gets that unknown ID, but, you have this problem anyway where the user exists. I say "simply" as in concept, not as in work required :-) -- Totally Holistic Enterprises Internet| P:+61 7 3870 0066 | Andrew The Internet (Aust) Pty Ltd | F:+61 7 3870 4477 | Milton ACN: 082 081 472 | M:+61 416 022 411 |72 Col .Sig PO Box 837 Indooroopilly QLD 4068|a...@theinternet.com.au|Specialist To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: RE: Need some advice regarding portable user IDs
On 18-Aug-99 Wilfredo Sanchez wrote: > when new media is available and it will try to mount it. The present > behaviour in Mac OS X Server is that everything mounted this way is > trusted, though the Finder should be requesting nosetuid; I should > check that. It's also possible that the kernel will number drives in > a different order (eg. /dev/sd0a this boot might be /dev/sd1a next > boot), particularly if you are shuffling drives around. (Remember > that hot-swap complicates this.) So a string like "/dev/sd0a" in > fstab is fragile, and it works out better if we keep that information > on the mounted media rather than on the root volume. You could wire all the disks down.. :) What happens with conflicting names? --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum pgpnBvN6vWP6u.pgp Description: PGP signature
Re: Need some advice regarding portable user IDs
At 7:17 PM -0700 8/17/99, Wilfredo Sanchez wrote: I think the desired behaviour would be that since this is effectively now Joe's zip disk, he should be able to do as he pleases. One proposal might be to give the console user the equivalent of root's priveledges on any removeable media he inserts into the machine while he's logged in on the console. While thinking about this, there's also the question of what access someone other than Joe would have to those files if they are (say) ssh-ed into the machine when he attaches the removable media. Not important for most home users, but relevant in "MacOS 10 Server" configurations. I forget exactly how nextstep did this, but there were some situations where it didn't work quite the way I wanted (at the time), and yet I couldn't decide on a clean way it should be changed so I'd get more of what I wanted... One problem with my proposal (setting security and perhaps other implications aside for the moment), is that knowing what media is removeable is becoming increasingly difficult. Hot-swappable drives (eg. FireWire) are effectively removeable, and may be transported between machines fairly regularly. Does firewire also allow multiple computers to access a given drive at the same time (by "same time", I mean "without having to rewire any hardware"). IBM's SSA disks also have this idea of multiple hosts for a single disk, even if the hosts consider that disk as "local"... So perhaps there needs to be a way to mark a drive as local (perhaps with a host ID of some sort?) and noticing when a volume is "foreign" that you need to do something special. Certainly you might want to ignore setuid bits, for starters. This could simply be something like fstab, which lists the local drives, and everything else isn't considered local. What happens when that entry isn't made right, though? To take another example from NeXTSTEP experience, consider the confusion caused when people did forget to make a correct fstab entry when they added a hard disk which WAS considered local and non-removable. Files were always owned by whoever logged in, and were actually written to the disk with UID=nobody or root (I forget which). This caused a different set of problems once they realized the mistake, and then put the correct fstab entry in. At that point, no one but root had access, since all the original-creator info was gone. So, if you do have a marker to indicate a local drive, what happens when the marker is switched on<->off? But then the question is, how do we want to deal with non-local filesystems? The ideal thing would be to have a way to transport user information with the filesystem (eg. uids on disk are mapped to system uids via a per-filesystem database with more global IDs like email addresses), but that could be expensive. Obviously I'm not helping much here... I have thought about this from time-to-time (due to my nextstations), and if I think about it enough I generally end up with a headache and go home. If considering some database like this, also consider that changing machines does not necessarily mean different accounting info. I may have several different G3's with the exact same accounts, quite delibrately, so I don't think a "host ID" marker is quite the right marker. A school with multiple labs of machines, for instance. Each lab might be the exact same id's, with different ids between labs. If I bounce around between thirty different machines in one lab, modifying files on my own little zip disk, it'll be weird to have that listed as thirty different UID's on the filesystem. I imagine it is workable, it just seems weird. Also note that different machines may deliberately have the same UID's, even though they are not using the same netinfo server. My machine at home vs my machine in the office, for instance. Some kind of signing/encryption of files (the actual data) might work, but I'm not sure an average person would want to try to keep track of the encryption keys (passwords, mappings between them, whatever). My head is starting to throb. I think I'll go home... --- Garance Alistair Drosehn = g...@eclipse.acs.rpi.edu Senior Systems Programmer or dro...@rpi.edu Rensselaer Polytechnic Institute To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: RE: Need some advice regarding portable user IDs
| I suppose you could carry a UID, GID mapping on the disks, and have mount look | out for it.. If you had a 'removable disk' flag in /etc/fstab, then have the | kernel look for those files, and use umapfs with them on the mounted FS. It | could be rather dangerous security wise though.. Maybe have an option somewhere | else (sysctl?) that tells mount wether removable disks are allowed to have | files that are executable/devices/s[ug]id on it. (ie automatically have -o | noexec,nosuid,nodevice done automatically based on user prefs) I would assume that unless the user has the appropriate priveledges and specifies otherwise, that all non-local media will not honor setuid and so on. So far, I'm thinking of local media as: 1) The root device, (which holds the kernel, so you have to trust it) 2) Volumes that were initialized locally and have been kept local. 3) Any devices the administrator has specified as such. #1 is easy. #2 implies some way of knowing what's been kept local, which is hard. #3 sounds easy. Aside from the setuid business, I might want to toss out any UID from non-local media, since they may not be relevant. On the other hand, they might be, and it would be nice if I could keep them in that case. And all of this wants happen without user intervention where possible. Oh, about fstab... right... (This is just FYI.) So we have a program called autodiskmount, which at boot time looks for available media and mounts it (mount point is determined by the volume label). We don't use fstab normally, mostly because we want users to be able to attach a drive and not have to configure it; it just shows up when they boot. The Finder does a similar thing: it gets notified when new media is available and it will try to mount it. The present behaviour in Mac OS X Server is that everything mounted this way is trusted, though the Finder should be requesting nosetuid; I should check that. It's also possible that the kernel will number drives in a different order (eg. /dev/sd0a this boot might be /dev/sd1a next boot), particularly if you are shuffling drives around. (Remember that hot-swap complicates this.) So a string like "/dev/sd0a" in fstab is fragile, and it works out better if we keep that information on the mounted media rather than on the root volume. -Fred -- Wilfredo Sanchez, wsanc...@apple.com Apple Computer, Inc., Core Operating Systems / BSD Technical Lead, Darwin Project 1 Infinite Loop, 302-4K, Cupertino, CA 95014 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
> A group of us at Apple are trying to figure out how to handle > situations where a filesystem with "foreign" user ID's are present. > The basic problem is that the user experience using Unix semantics > are not really pleasant. I think some examples would help: Basically, you have two alternatives; transport the user credentials with the media, or map the credentials on the media to something that's more sensible. In different situations, one or the other of these might make more sense. Throwing some examples: a) You put some files on a removable device. They are "owned" by you. You give the media to someone else, who then mounts it on their own system (which is logically totally disjoint to yours). The desired goal is for the recipient to be able to access the files just as you could. In this case, possession of the media is the desired credential, so the media itself should (ideally) not contain any other credential information (or it should be ignored). b) You move a disk from one server on your network to another. The disk contains files owned by hundreds of users. The desired goal in this case is for the users that could access the files on the first server to be able to access the same files in the same fashion when the disk is on the second server. In this case, the credentials are external to the media and need to be verified against it. One possible way of differentiating these two cases would be to have a flag associated with the media (filesystem perhaps) that indicates whether the media has "security features" enabled. If it doesn't, the media should appear as though everything on it is owned by the user that has mounted it. You would default "security features" off when removable media were initialised. With "security features" on, the media behaviour would be what we consider normal; permissions on files, directories etc. are checked and so forth. The issues related to migrating volumes with "security features" enabled are more interesting; the only atomic way to migrate the credential verification information is to write it to the disk before it's removed. eg. You would offer a "prepare disk for export" option which scanned the disk and wrote out a passwd/group-style database containing the credentials for the uids and gids represented on the volume; this would then need to be integrated into the new system in a suitable fashion, either by merging apparently identical users/groups (and possibly scanning the disk volume to update uid/gid values) into the new system's authentication databases (this would have some perhaps slightly interesting consequences), or by applying the per-volume list as a translation to allow users known to the media to access the system in some suitably limited fashion in order to get at the data on the media. One alternative that would allow migration within a heterogenous network but prevent dealing with the quite complex issues of migrating credentials would simply be to scan every volume with "security features" enabled which didn't appear to have been last used locally and check that all the users represented there were locally valid. This would benefit from having the uid:username and gid:groupname mappings available (maybe it would be faster just to dump the entire database to the disk?) since the scan could fall back to using a network authentication service (NIS, etc.) to obtain the data required to support the users locally. I'm probably being as confusing as you thought you were. Any of this any use? -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ [EMAIL PROTECTED] \\-- Joseph Merrick \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
+[ Wilfredo Sanchez ]- | A group of us at Apple are trying to figure out how to handle | situations where a filesystem with "foreign" user ID's are present. | The basic problem is that the user experience using Unix semantics | are not really pleasant. I think some examples would help: Why not simply translate unknown ids to the current user? I don't mean modifying the owners on disk. The real problem comes if a new user gets that unknown ID, but, you have this problem anyway where the user exists. I say "simply" as in concept, not as in work required :-) -- Totally Holistic Enterprises Internet| P:+61 7 3870 0066 | Andrew The Internet (Aust) Pty Ltd | F:+61 7 3870 4477 | Milton ACN: 082 081 472 | M:+61 416 022 411 |72 Col .Sig PO Box 837 Indooroopilly QLD 4068|[EMAIL PROTECTED]|Specialist To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: RE: Need some advice regarding portable user IDs
On Tue, Aug 17, 1999 at 07:46:37PM -0700, Wilfredo Sanchez wrote: > Yes, the fancy command is what the Finder does for him. Options > are details, and not really interesting. The question is what should > the behaviour be, and what's happening underneath the covers to > support that? Are we mapping UID's to something meaningful? How? > Or is Joe a superuser for that volume? Which volumes get treated > this way, and how to you choose them? I think it's pretty much a given that there's going to have to be configuration for this to say which devices are "special" in this way (and perhaps for which users and under what conditions they are special). Ok, so given that /dev/fd0, for example, is marked as "insecure", some mechanism lets me say "anyone who is in group 'operator' can mount /dev/fd0 in such a way that they appear to own all the files (and when they do so, default to turning on nosuid and such)". I think you're looking for a solution to the common problem of someone popping a Zip disk in the drive. Devising a mechanism to perform a complicated mapping and carrying around of user information on removable media sounds like overkill (not to mention it wouldn't work for "just any" UFS Zip disk you have lying around, only the ones that were built on MacOS). I don't know what the administration model is for MacOS, but I think that if someone's moving a hard drive from one machine to another, it isn't unfair to expect a step up in complexity and privileges required, versus a simple floppy.. er, I mean Zip drive. You can lead a Unix to Macintosh, but you can't make it drool. Under the hood, performing the gyrations necessary to mount it through umap is an interesting approach, although last time I touched mount_umap it easily panicked my machine. It certainly seems better than hacking the kernel directly (an approach which the other BSDs will be less keen to accept). Good luck with it. -- Christopher Masto Senior Network Monkey NetMonger Communications ch...@netmonger.neti...@netmonger.nethttp://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: RE: Need some advice regarding portable user IDs
On 18-Aug-99 Wilfredo Sanchez wrote: > when new media is available and it will try to mount it. The present > behaviour in Mac OS X Server is that everything mounted this way is > trusted, though the Finder should be requesting nosetuid; I should > check that. It's also possible that the kernel will number drives in > a different order (eg. /dev/sd0a this boot might be /dev/sd1a next > boot), particularly if you are shuffling drives around. (Remember > that hot-swap complicates this.) So a string like "/dev/sd0a" in > fstab is fragile, and it works out better if we keep that information > on the mounted media rather than on the root volume. You could wire all the disks down.. :) What happens with conflicting names? --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum PGP signature
Re: Need some advice regarding portable user IDs
At 7:17 PM -0700 8/17/99, Wilfredo Sanchez wrote: > I think the desired behaviour would be that since this is >effectively now Joe's zip disk, he should be able to do as he >pleases. One proposal might be to give the console user the >equivalent of root's priveledges on any removeable media he inserts >into the machine while he's logged in on the console. While thinking about this, there's also the question of what access someone other than Joe would have to those files if they are (say) ssh-ed into the machine when he attaches the removable media. Not important for most home users, but relevant in "MacOS 10 Server" configurations. I forget exactly how nextstep did this, but there were some situations where it didn't work quite the way I wanted (at the time), and yet I couldn't decide on a clean way it should be changed so I'd get more of what I wanted... > One problem with my proposal (setting security and perhaps other >implications aside for the moment), is that knowing what media is >removeable is becoming increasingly difficult. Hot-swappable drives >(eg. FireWire) are effectively removeable, and may be transported >between machines fairly regularly. Does firewire also allow multiple computers to access a given drive at the same time (by "same time", I mean "without having to rewire any hardware"). IBM's SSA disks also have this idea of multiple hosts for a single disk, even if the hosts consider that disk as "local"... > So perhaps there needs to be a way to mark a drive as local >(perhaps with a host ID of some sort?) and noticing when a volume is >"foreign" that you need to do something special. Certainly you might >want to ignore setuid bits, for starters. This could simply be >something like fstab, which lists the local drives, and everything >else isn't considered local. What happens when that entry isn't made right, though? To take another example from NeXTSTEP experience, consider the confusion caused when people did forget to make a correct fstab entry when they added a hard disk which WAS considered local and non-removable. Files were always owned by whoever logged in, and were actually written to the disk with UID=nobody or root (I forget which). This caused a different set of problems once they realized the mistake, and then put the correct fstab entry in. At that point, no one but root had access, since all the original-creator info was gone. So, if you do have a marker to indicate a local drive, what happens when the marker is switched on<->off? > But then the question is, how do we want to deal with non-local >filesystems? The ideal thing would be to have a way to transport >user information with the filesystem (eg. uids on disk are mapped to >system uids via a per-filesystem database with more global IDs like >email addresses), but that could be expensive. Obviously I'm not helping much here... I have thought about this from time-to-time (due to my nextstations), and if I think about it enough I generally end up with a headache and go home. If considering some database like this, also consider that changing machines does not necessarily mean different accounting info. I may have several different G3's with the exact same accounts, quite delibrately, so I don't think a "host ID" marker is quite the right marker. A school with multiple labs of machines, for instance. Each lab might be the exact same id's, with different ids between labs. If I bounce around between thirty different machines in one lab, modifying files on my own little zip disk, it'll be weird to have that listed as thirty different UID's on the filesystem. I imagine it is workable, it just seems weird. Also note that different machines may deliberately have the same UID's, even though they are not using the same netinfo server. My machine at home vs my machine in the office, for instance. Some kind of signing/encryption of files (the actual data) might work, but I'm not sure an average person would want to try to keep track of the encryption keys (passwords, mappings between them, whatever). My head is starting to throb. I think I'll go home... --- Garance Alistair Drosehn = [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Institute To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: RE: Need some advice regarding portable user IDs
| I suppose you could carry a UID, GID mapping on the disks, and have mount look | out for it.. If you had a 'removable disk' flag in /etc/fstab, then have the | kernel look for those files, and use umapfs with them on the mounted FS. It | could be rather dangerous security wise though.. Maybe have an option somewhere | else (sysctl?) that tells mount wether removable disks are allowed to have | files that are executable/devices/s[ug]id on it. (ie automatically have -o | noexec,nosuid,nodevice done automatically based on user prefs) I would assume that unless the user has the appropriate priveledges and specifies otherwise, that all non-local media will not honor setuid and so on. So far, I'm thinking of local media as: 1) The root device, (which holds the kernel, so you have to trust it) 2) Volumes that were initialized locally and have been kept local. 3) Any devices the administrator has specified as such. #1 is easy. #2 implies some way of knowing what's been kept local, which is hard. #3 sounds easy. Aside from the setuid business, I might want to toss out any UID from non-local media, since they may not be relevant. On the other hand, they might be, and it would be nice if I could keep them in that case. And all of this wants happen without user intervention where possible. Oh, about fstab... right... (This is just FYI.) So we have a program called autodiskmount, which at boot time looks for available media and mounts it (mount point is determined by the volume label). We don't use fstab normally, mostly because we want users to be able to attach a drive and not have to configure it; it just shows up when they boot. The Finder does a similar thing: it gets notified when new media is available and it will try to mount it. The present behaviour in Mac OS X Server is that everything mounted this way is trusted, though the Finder should be requesting nosetuid; I should check that. It's also possible that the kernel will number drives in a different order (eg. /dev/sd0a this boot might be /dev/sd1a next boot), particularly if you are shuffling drives around. (Remember that hot-swap complicates this.) So a string like "/dev/sd0a" in fstab is fragile, and it works out better if we keep that information on the mounted media rather than on the root volume. -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: RE: Need some advice regarding portable user IDs
At 12:25 PM +0930 8/18/99, Daniel O'Connor wrote: On 18-Aug-99 Wilfredo Sanchez wrote: >Joe doesn't use the shell. The Finder will do this for him; when > you insert a floppy in Mac OS, it gets mounted and shows up on your > desktop. This is the case with all media. Yes... Why is this a FreeBSD problem then? I would have thought it would be up to MacOS to do the UID remapping (I must be missing something) The question is being sent to several different BSD groups. One of the newer BSD's being MacOS X (Ten) from Apple (follow on to NeXTSTEP, except that it's a much more MacOS-ish as far as the user interface). MacOS X (Ten) Server already uses code from FreeBSD, NetBSD, and OpenBSD. This isn't a freebsd problem per se, but wouldn't it be nice if Apple went with a solution that made sense to the other BSD groups? (particularly if someone in *BSD-land has already thought about the same issues). Some of Apple's OS-level changes have been donated back to the BSD groups, and if they implement a good solution to this problem then the other BSD's might want to pick it up. It's nice to see them asking for ideas before casting some implementation in stone... --- Garance Alistair Drosehn = g...@eclipse.acs.rpi.edu Senior Systems Programmer or dro...@rpi.edu Rensselaer Polytechnic Institute To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: RE: Need some advice regarding portable user IDs
On Tue, Aug 17, 1999 at 07:46:37PM -0700, Wilfredo Sanchez wrote: > Yes, the fancy command is what the Finder does for him. Options > are details, and not really interesting. The question is what should > the behaviour be, and what's happening underneath the covers to > support that? Are we mapping UID's to something meaningful? How? > Or is Joe a superuser for that volume? Which volumes get treated > this way, and how to you choose them? I think it's pretty much a given that there's going to have to be configuration for this to say which devices are "special" in this way (and perhaps for which users and under what conditions they are special). Ok, so given that /dev/fd0, for example, is marked as "insecure", some mechanism lets me say "anyone who is in group 'operator' can mount /dev/fd0 in such a way that they appear to own all the files (and when they do so, default to turning on nosuid and such)". I think you're looking for a solution to the common problem of someone popping a Zip disk in the drive. Devising a mechanism to perform a complicated mapping and carrying around of user information on removable media sounds like overkill (not to mention it wouldn't work for "just any" UFS Zip disk you have lying around, only the ones that were built on MacOS). I don't know what the administration model is for MacOS, but I think that if someone's moving a hard drive from one machine to another, it isn't unfair to expect a step up in complexity and privileges required, versus a simple floppy.. er, I mean Zip drive. You can lead a Unix to Macintosh, but you can't make it drool. Under the hood, performing the gyrations necessary to mount it through umap is an interesting approach, although last time I touched mount_umap it easily panicked my machine. It certainly seems better than hacking the kernel directly (an approach which the other BSDs will be less keen to accept). Good luck with it. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: RE: Need some advice regarding portable user IDs
On 18-Aug-99 Wilfredo Sanchez wrote: >I'm trying to support a user experience similar to Mac OS using > BSD underneath (for Mac OS version 10). The goal being simplicity > for the user, which I think might interest some FreeBSD users as well > as my customers. Right.. sorry, I didn't mean to sound rude :) > | map (like NIS)? >And what happens accross NIS domains? Design failure :) I suppose you could carry a UID, GID mapping on the disks, and have mount look out for it.. If you had a 'removable disk' flag in /etc/fstab, then have the kernel look for those files, and use umapfs with them on the mounted FS. It could be rather dangerous security wise though.. Maybe have an option somewhere else (sysctl?) that tells mount wether removable disks are allowed to have files that are executable/devices/s[ug]id on it. (ie automatically have -o noexec,nosuid,nodevice done automatically based on user prefs) If there where no mapping files on the disk have a default setting.. Perhaps you could 'sign' the files on the disk so that when you inserted it, it checked the mapping files where signed by someone so you could opt to trust certain people, and have less restrictive options for their disks. You could even have it so it asks for your key phrase (thinking pgp/ssh terms) when you insert the disk so you can verify the person, which would prevent someone getting a disk trusted by you and modifying it and using it in your machine. Ahh, the complexities are endless :) --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum pgp7B5q3NN7QE.pgp Description: PGP signature
