From: Michael R. <mc...@sa...> - 2003-09-02 16:30:11
|
-----BEGIN PGP SIGNED MESSAGE----- >>>>> "Henrik" == Henrik Nordstrom <hn...@ma...> writes: Henrik> The rw mount option works fine here, but I am not using a full Henrik> system Henrik> image but an image primarily designed for read-only root so mount Henrik> is happy Henrik> in either case here.. I went back to 2.4.19 + patch 47, with the same boot scripts (i.e. rootfs=, not ubd0=) No problem there. Henrik> Verify the permissions again.. also try booting in a emergency Henrik> shell Henrik> (init=/bin/sh) to verify that it is not your system image which Henrik> remounts Henrik> the root read-only while booting.. Hmm. that's possible, but why would 2.4.19 not care? Let me try this hypothesis.... you are partly right. It looks like the only real complaint is that it can't open /etc/mtab~ at boot time, and it complains, and the /etc/mtab file isn't created properly: Mounted devfs on /dev INIT: version 2.78 booting Activating swap... can't open lock file /etc/mtab~: Permission denied (use -n flag to override) can't open lock file /etc/mtab~: Permission denied (use -n flag to override) ... /etc/mtab~ is created with mode 0, and this shows up in the host that way as well. Perhaps this is the real problem. Actually, I don't seem to be able to reproduce the read-only root now! I swear it was complaining that it couldn't write, because the file system was read only before. cassidy-[nightly/testing/klips/east-icmp-01] mcr 1141 %ls -lta /c2/freeswan/sandboxes/nightly/UMLPOOL/east/root/etc/mtab* - -rw-r--r-- 1 mcr mcr 0 Sep 2 12:24 /c2/freeswan/sandboxes/nightly/UMLPOOL/east/root/etc/mtab - ---------- 1 mcr mcr 0 Sep 2 12:24 /c2/freeswan/sandboxes/nightly/UMLPOOL/east/root/etc/mtab~ I tried removing the file in my boot script first, but that doesn't help. ] Out and about in Ottawa. hmmm... beer. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mc...@sa... http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys - custom hacks make this fully PGP2 compat iQCVAwUBP1TFRIqHRg3pndX9AQEZjAQAxTM87CRMtT3dLR9XWK8kTruB4bITRONS tuPlUVq9Pp1cNUzwycKK2SIJqBfzOvlkNCI9TQ4B3mzsfS8zNQPdBXJk/Iyd6X7F VTmM91KMoPCmCwLihcxxT6Dx86rPo1vu9xc338wnkhjQ9/BkCuhQFZ5YgGKcGqjf /N7s/nDoB+U= =L/3s -----END PGP SIGNATURE----- |
From: Michael R. <mc...@sa...> - 2003-09-05 16:30:19
|
-----BEGIN PGP SIGNED MESSAGE----- >>>>> "Adam" == Adam Heath <ad...@do...> writes: Adam> On Fri, 5 Sep 2003, Michael Richardson wrote: >> >> I propose: stat(), save permissions chmod(u+rw) (as appropriate for >> >> the open) open() chmod(oldperms) >> Matt> Sounds like a recipe for lots of race conditions. >> Uh, how? Remember, this is in the kernel. We have locks. >> >> If two UMLs come along, using the same rootfs, well, that's a >> different problem. Adam> No, it's a problem. Just because there's no race in the emulated Adam> environment, doesn't mean there isn't a race in the host. I don't think that hostfs provides any inter-UML locking guarantees. What do we do with flock(2)? If you like, we can flock(2) the file too while we play with it. ] Out and about in Ottawa. hmmm... beer. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mc...@sa... http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys - custom hacks make this fully PGP2 compat iQCVAwUBP1i5x4qHRg3pndX9AQErKAQAjb02jUIC6x+RT3ojY8Ta9G3wuyqJFs35 O/ySSn/73X5kaAc3Vh96zSkaLI3+hE3LTR+CWhtbfSGFZCXDjcahVu9/2wuUm8Ud 7p6/1C7ZwNOZk5EJk/8rGpHP2oJAl4qY/bvcSoZ9f1JequzCilhjyxuua/4t09kW ZxqtZdP9nEM= =TF2P -----END PGP SIGNATURE----- |
From: Adam H. <ad...@do...> - 2003-09-05 16:46:23
|
On Fri, 5 Sep 2003, Michael Richardson wrote: > Adam> No, it's a problem. Just because there's no race in the emulated > Adam> environment, doesn't mean there isn't a race in the host. > > I don't think that hostfs provides any inter-UML locking guarantees. > What do we do with flock(2)? > > If you like, we can flock(2) the file too while we play with it. This has not hing to do with inter-uml. This has everything to do with uml behaving like a sane, properly written application. If 2 normal applications did something like this, they'd be buggy just as well. |
From: <st...@ni...> - 2003-09-05 17:24:30
|
The problem occurs when you create a file you are later not allowed to open if I'm seeing this right, so, the best fix would be not to close the file when we create them in the first place. Fix the behavour that we create file close file open file again do action If that is redone till create file do action The mode issue goes pretty much away, since trying to open a file you are not allowed to read will normally fail both in host and uml. Only problem is when creating new files as far as I can see. Might be more job, but the result is more cleaner than than chmod stuff on the fly. Stian This mail has been scanned for known viruses on an open, Linux-based mailsystem developed by http://Knowledge-Network.no and http://Nixia.no. |
From: Matt Z. <md...@de...> - 2003-09-05 18:19:02
|
On Fri, Sep 05, 2003 at 05:14:57PM +0200, st...@ni... wrote: > The problem occurs when you create a file you are later not allowed to > open if I'm seeing this right, so, the best fix would be not to close the > file when we create them in the first place. Fix the behavour that we > > create file > close file > open file again > do action > > If that is redone till > > create file > do action > > > The mode issue goes pretty much away, since trying to open a file you are > not allowed to read will normally fail both in host and uml. Only problem > is when creating new files as far as I can see. > > > Might be more job, but the result is more cleaner than than chmod stuff on > the fly. That is what the original bug was, and that is how it was fixed. Michael's problem is that mount(8) creates a file with mode 0, closes it, and then tries to open it. -- - mdz |
From: Michael R. <mc...@sa...> - 2003-09-05 17:59:38
|
-----BEGIN PGP SIGNED MESSAGE----- >>>>> "stian" == stian <st...@ni...> writes: stian> The problem occurs when you create a file you are later not stian> allowed to stian> open if I'm seeing this right, so, the best fix would be not to stian> close the stian> file when we create them in the first place. Fix the behavour that stian> we I believe that we do this because in TT mode at least, we may have to open it in multiple processes. So the fix would work for SKAS, but not TT mode. stian> The mode issue goes pretty much away, since trying to open a file stian> you are not allowed to read will normally fail both in host and stian> uml. Only problem is when creating new files as far as I can see. Root can open a file for write that doesn't have write permissions. ] Out and about in Ottawa. hmmm... beer. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mc...@sa... http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys - custom hacks make this fully PGP2 compat iQCVAwUBP1jOyoqHRg3pndX9AQG4cAP/codBpW4FkhBKFrLpDmFpp5+tqy0hPVlt VFwfdJ3nTKJzWJBkt82FVH9J5/2MkVTN0w+V4/LWw/DskOz22YdIczyoFZIXTChK IGHncjsx8FMhhgxwBZ8s9toHluQGG8t88ZRETDLQQmm3BIBGfUmlsVUdoLRjKhvg dyi7xT4sT3s= =mfEh -----END PGP SIGNATURE----- |
From: Henrik N. <hn...@ma...> - 2003-09-03 09:32:30
|
tis 2003-09-02 klockan 18.28 skrev Michael Richardson: > can't open lock file /etc/mtab~: Permission denied (use -n flag to override) > can't open lock file /etc/mtab~: Permission denied (use -n flag to override) > ... > > /etc/mtab~ is created with mode 0, and this shows up in the host that way > as well. Perhaps this is the real problem. Right.. hostfs will almost certainly not work well with file mode 0 until the virtual permissions layer is implemented. Today hostfs directly maps permissions to the host files, which breaks root semantics for UML. Normally root expects that mode does not matter when reading/writing files, but when using hostfs it does matter when UML accesses the host. Regards Henrik -- Henrik Nordstrom <hn...@ma...> MARA Systems AB |
From: Matt Z. <md...@de...> - 2003-09-03 15:47:24
|
On Wed, Sep 03, 2003 at 11:32:18AM +0200, Henrik Nordstrom wrote: > Right.. hostfs will almost certainly not work well with file mode 0 > until the virtual permissions layer is implemented. > > Today hostfs directly maps permissions to the host files, which breaks > root semantics for UML. Normally root expects that mode does not matter > when reading/writing files, but when using hostfs it does matter when > UML accesses the host. If your UML is dynamically linked, you can run it inside fakeroot to get these semantics. It would be very handy to have this implemented in UML itself, though. I work around it in various annoying ways at the moment. -- - mdz |
From: Michael R. <mc...@sa...> - 2003-09-03 18:24:11
|
-----BEGIN PGP SIGNED MESSAGE----- >>>>> "Henrik" == Henrik Nordstrom <hn...@ma...> writes: >> /etc/mtab~ is created with mode 0, and this shows up in the host that >> way >> as well. Perhaps this is the real problem. Henrik> Right.. hostfs will almost certainly not work well with file mode 0 Henrik> until the virtual permissions layer is implemented. Henrik> Today hostfs directly maps permissions to the host files, which Henrik> breaks But, did this change between 2.4.19-47 and 2.4.20-8? 2.4.19 works just fine. ] Out and about in Ottawa. hmmm... beer. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mc...@sa... http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys - custom hacks make this fully PGP2 compat iQCVAwUBP1YxfYqHRg3pndX9AQGFYQP+L9zsftdJvN22ca1Ty10VlDdqGJxnQ+2d 7ntU0LcXZVvnnQEZE8tH0HqDK4NrHVZIucFbDJahJmeSMZ+i+cuGAkjx8Qt3K/Wi Mf927+F2YblgCunTByDatZlcfuangH44kcrIcljpJuZdYS/sljsKRFLT76urEYpK E5Pc8YHpjfc= =YQW5 -----END PGP SIGNATURE----- |
From: Henrik N. <hn...@ma...> - 2003-09-03 18:55:35
|
On Wed, 3 Sep 2003, Michael Richardson wrote: > But, did this change between 2.4.19-47 and 2.4.20-8? Not that I know of, but some timing may have changed making the problem of the dual permission layers more apparent compared to earlier.. As I said I mostly use hostfs in read-only mode, and sometimes in read-write for plain filetransfer purposes, so I barely if ever run into this kind of issues other than when playing around testing what would happen.. Regards Henrik |
From: Matt Z. <md...@de...> - 2003-09-03 19:16:34
|
On Wed, Sep 03, 2003 at 02:22:54PM -0400, Michael Richardson wrote: > >>>>> "Henrik" == Henrik Nordstrom <hn...@ma...> writes: > >> /etc/mtab~ is created with mode 0, and this shows up in the host that > >> way > >> as well. Perhaps this is the real problem. > > Henrik> Right.. hostfs will almost certainly not work well with file mode 0 > Henrik> until the virtual permissions layer is implemented. > > Henrik> Today hostfs directly maps permissions to the host files, which > Henrik> breaks > > But, did this change between 2.4.19-47 and 2.4.20-8? > > 2.4.19 works just fine. Yes, it did. Things were changed so that files could be created read-only with O_RDWR. -- - mdz |
From: Michael R. <mc...@sa...> - 2003-09-05 00:55:51
|
-----BEGIN PGP SIGNED MESSAGE----- >>>>> "Matt" == Matt Zimmerman <md...@de...> writes: >> >>>>> "Henrik" == Henrik Nordstrom <hn...@ma...> writes: >> >> /etc/mtab~ is created with mode 0, and this shows up in the host that >> >> way >> >> as well. Perhaps this is the real problem. >> Henrik> Right.. hostfs will almost certainly not work well with file mode 0 Henrik> until the virtual permissions layer is implemented. >> Henrik> Today hostfs directly maps permissions to the host files, which Henrik> breaks >> >> But, did this change between 2.4.19-47 and 2.4.20-8? >> >> 2.4.19 works just fine. Matt> Yes, it did. Things were changed so that files could be created Matt> read-only Matt> with O_RDWR. okay.. Makes sense. But, since they are mode 0, we can't open them as the user, which root inside could do. Is there some compromise that we can do until we have the permissions layer in place? Like, forcing u+r on the underlying file maybe? Or, if the mode is 0, and uid=0 inside, that we chmod u+r, then open? I'm happy to code this, but I don't want to waste time here :-) I could stay with 2.4.19-47, but we'd like to run on RH9 ;-) ] Out and about in Ottawa. hmmm... beer. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mc...@sa... http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys - custom hacks make this fully PGP2 compat iQCVAwUBP1fe5YqHRg3pndX9AQHR2wP+JaOp4GcXqIdz1ewR3Zh6+tcu5mi5EOZW aWbya1Xq2m+EsG0d8hs3o3Jsuq2oVrLtncy+OYs7An+GDOL0/y7QmrSqnXS38grC NCyYi5C25grnjNq17JWLtOzsE9c8VqTLujMhkF8mV88IHtd9sapOXuiXs+NkZDuS WytpNbf9oW4= =dbdy -----END PGP SIGNATURE----- |
From: Matt Z. <md...@de...> - 2003-09-05 01:10:52
|
On Thu, Sep 04, 2003 at 08:55:03PM -0400, Michael Richardson wrote: > okay.. Makes sense. But, since they are mode 0, we can't open them as > the user, which root inside could do. Is there some compromise that we can > do until we have the permissions layer in place? > Like, forcing u+r on the underlying file maybe? The problem I ran into which led me to this bug was extracting tar archives. When they contain read-only files, tar opens them for writing with read-only permissions. Since UML was creating the file and then, subsequently, attempting to open it for writing, the second open failed. I think that in general, having the permissions silently changed would be unwise, though I admit that u-r permissions are weird at best. It would seem better to have mount fixed to stop doing this strange thing, and eventually to emulate full permission control in hostfs. -- - mdz |
From: Michael R. <mc...@sa...> - 2003-09-05 13:44:39
|
-----BEGIN PGP SIGNED MESSAGE----- >>>>> "Matt" == Matt Zimmerman <md...@de...> writes: >> okay.. Makes sense. But, since they are mode 0, we can't open them as >> the user, which root inside could do. Is there some compromise that we >> can >> do until we have the permissions layer in place? >> Like, forcing u+r on the underlying file maybe? Matt> The problem I ran into which led me to this bug was extracting tar Matt> archives. Matt> When they contain read-only files, tar opens them for writing with Matt> read-only Matt> permissions. Since UML was creating the file and then, subsequently, Matt> attempting to open it for writing, the second open failed. How is this the correct thing to do for the UML then? What bug did you uncover? Matt> I think that in general, having the permissions silently changed Matt> would be Matt> unwise, though I admit that u-r permissions are weird at best. It Well, if the opener is root, you get to ignore the permissions. That means that something has to break. I propose: stat(), save permissions chmod(u+rw) (as appropriate for the open) open() chmod(oldperms) Matt> would Matt> seem better to have mount fixed to stop doing this strange thing, and Matt> eventually to emulate full permission control in hostfs. Well, leaving us in a lurch is decidely not friendly. Your fix has broken debian potato's mount. Being able to run other distros, versions, etc. inside of UML is one of the major features of UML. ] Out and about in Ottawa. hmmm... beer. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mc...@sa... http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys - custom hacks make this fully PGP2 compat iQCVAwUBP1iTG4qHRg3pndX9AQFsbQP9FP28wQ6dkztxuLL+No3+3sc/nmh7ZSyC YKmwdPdXBWJ8bMdQUdW2RAnGOXKHUtZ70S4pUOMljQe2pWkRs4aCspAdKpaQwG2c iLmqMabpoH5eACRgxfeuqgHVdDu0ognFJELkT61pAQrN66nAfGIYvN59cRIPjR56 PXZdGyk1/G4= =lErV -----END PGP SIGNATURE----- |
From: Matt Z. <md...@de...> - 2003-09-05 14:01:42
|
On Fri, Sep 05, 2003 at 09:43:56AM -0400, Michael Richardson wrote: > > >>>>> "Matt" == Matt Zimmerman <md...@de...> writes: > Matt> The problem I ran into which led me to this bug was extracting tar > Matt> archives. > Matt> When they contain read-only files, tar opens them for writing with > Matt> read-only > Matt> permissions. Since UML was creating the file and then, subsequently, > Matt> attempting to open it for writing, the second open failed. > > How is this the correct thing to do for the UML then? > What bug did you uncover? I described it above. tar was completely unable to extract files with read-only permissions. > Matt> I think that in general, having the permissions silently changed > Matt> would be > Matt> unwise, though I admit that u-r permissions are weird at best. It > > Well, if the opener is root, you get to ignore the permissions. That means > that something has to break. > > I propose: > stat(), save permissions > chmod(u+rw) (as appropriate for the open) > open() > chmod(oldperms) Sounds like a recipe for lots of race conditions. > Matt> would > Matt> seem better to have mount fixed to stop doing this strange thing, and > Matt> eventually to emulate full permission control in hostfs. > > Well, leaving us in a lurch is decidely not friendly. > Your fix has broken debian potato's mount. Being able to run other distros, > versions, etc. inside of UML is one of the major features of UML. OK, so mount is already fixed. So the only problem is that you can't use an old, mildly buggy version of mount with root-hostfs as a non-root user on the host. I'd rather be able to extract tar files than have that scenario. You must have already worked around some other problems in order to run potato in this configuration; it wouldn't work out of the box with a 2.4 kernel. How are you managing device nodes? Loading any kernel modules? -- - mdz |
From: Michael R. <mc...@sa...> - 2003-09-05 15:52:04
|
-----BEGIN PGP SIGNED MESSAGE----- >>>>> "Matt" == Matt Zimmerman <md...@de...> writes: >> Well, if the opener is root, you get to ignore the permissions. That >> means that something has to break. >> >> I propose: stat(), save permissions chmod(u+rw) (as appropriate for >> the open) open() chmod(oldperms) Matt> Sounds like a recipe for lots of race conditions. Uh, how? Remember, this is in the kernel. We have locks. If two UMLs come along, using the same rootfs, well, that's a different problem. >> Well, leaving us in a lurch is decidely not friendly. Your fix has >> broken debian potato's mount. Being able to run other distros, >> versions, etc. inside of UML is one of the major features of UML. Matt> OK, so mount is already fixed. So the only problem is that you Matt> can't use an old, mildly buggy version of mount with root-hostfs as Matt> a non-root user on the host. I'd rather be able to extract tar Matt> files than have that scenario. Okay. I see. Matt> You must have already worked around some other problems in order to Matt> run potato in this configuration; it wouldn't work out of the box Matt> with a 2.4 kernel. How are you managing device nodes? Loading any Matt> kernel modules? Works fine for me. It has been working fine for two years now. ] Out and about in Ottawa. hmmm... beer. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mc...@sa... http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys - custom hacks make this fully PGP2 compat iQCVAwUBP1iw2YqHRg3pndX9AQEzJwP/T0G/+pKEc91jtkOOaVOcHEhGA7kyt+u2 fum+nFEkyeI7P/B+gn56j7ilGflQF/9PJUAZliQByXSh3kT+t+K6QfANV7b9MRSI V6tk23VZ9aiUJffqo0pirs0l2ePFfgR09kw7U0se8IGM0c/+OWvPYZSXClEt8yGb ptqs9Hzamms= =Biha -----END PGP SIGNATURE----- |
From: Adam H. <ad...@do...> - 2003-09-05 16:08:23
|
On Fri, 5 Sep 2003, Michael Richardson wrote: > >> I propose: stat(), save permissions chmod(u+rw) (as appropriate for > >> the open) open() chmod(oldperms) > > Matt> Sounds like a recipe for lots of race conditions. > > Uh, how? > Remember, this is in the kernel. We have locks. > > If two UMLs come along, using the same rootfs, well, that's a different > problem. No, it's a problem. Just because there's no race in the emulated environment, doesn't mean there isn't a race in the host. |
From: Matt Z. <md...@de...> - 2003-09-05 16:13:03
|
On Fri, Sep 05, 2003 at 11:50:50AM -0400, Michael Richardson wrote: > >>>>> "Matt" == Matt Zimmerman <md...@de...> writes: > Matt> Sounds like a recipe for lots of race conditions. > > Uh, how? > Remember, this is in the kernel. We have locks. There is not currently a lock held by hostfs_file_open that I see; this does not seem like sufficient reason to make it impossible to do two opens simultaneously. > If two UMLs come along, using the same rootfs, well, that's a different > problem. It's the same problem, and it affects any shared hostfs, not only root (unless you were planning to add a test for that). > Matt> You must have already worked around some other problems in order to > Matt> run potato in this configuration; it wouldn't work out of the box > Matt> with a 2.4 kernel. How are you managing device nodes? Loading any > Matt> kernel modules? > > Works fine for me. > It has been working fine for two years now. What works fine? The modutils in potato doesn't support 2.4 kernels, only root is allowed to create device nodes in the host filesystem, and the paths in /etc/inittab and everywhere else won't exist with devfs unless devfsd is running. You're obviously working around these problems. -- - mdz |
From: Michael R. <mc...@sa...> - 2003-09-05 17:38:34
|
-----BEGIN PGP SIGNED MESSAGE----- >>>>> "Matt" == Matt Zimmerman <md...@de...> writes: >> Works fine for me. It has been working fine for two years now. Matt> What works fine? The modutils in potato doesn't support 2.4 Matt> kernels, only root is allowed to create device nodes in the host I don't use modutils from potato, since I build static kernels. Matt> filesystem, and the paths in /etc/inittab and everywhere else won't Matt> exist with devfs unless devfsd is running. You're obviously Matt> working around these problems. wasn't me. *someone* did this when they created the root system. If you have a simple /sbin/mount that you can recommend that solves my problem, I will consider using it. ] Out and about in Ottawa. hmmm... beer. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mc...@sa... http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys - custom hacks make this fully PGP2 compat iQCVAwUBP1jJ8IqHRg3pndX9AQHU2wQAqUYSRG2Sq7juITMIoGRQn0RyNnT2tG90 CvUVozOCCuayBdVnZj0b3X/biqYjZ/es/5dH4xQWtskE266mE91iq7aJrykM/eF/ ai8+1yesR8MWxNr17oF49A5TzgWGnClNyHXRkocJPooTF0Se0zwv87AoG08IOIrT sAziFFX0tjM= =TBUB -----END PGP SIGNATURE----- |
From: Matt Z. <md...@de...> - 2003-09-05 18:02:48
|
On Fri, Sep 05, 2003 at 01:37:53PM -0400, Michael Richardson wrote: > If you have a simple /sbin/mount that you can recommend that solves my > problem, I will consider using it. The fact that you said it broke _potato_'s mount, specifically, led me to believe that newer versions did not do this (they do). However, the fix to mount is trivial, so you can easily create an /sbin/mount which should work. -- - mdz |
From: Michael R. <mc...@sa...> - 2003-09-05 18:39:41
|
-----BEGIN PGP SIGNED MESSAGE----- >>>>> "Matt" == Matt Zimmerman <md...@de...> writes: >> If you have a simple /sbin/mount that you can recommend that solves my >> problem, I will consider using it. Matt> The fact that you said it broke _potato_'s mount, specifically, led Matt> me to believe that newer versions did not do this (they do). Ah, so your fix basically breaks all distros? I have no idea. Then clearly it needs to be fixed in the kernel, don't you think? Matt> However, the fix to mount is trivial, so you can easily create an Matt> /sbin/mount which should work. I think that removing your patch is a better idea. Find another way to make tar happy. Booting the system is pretty important. ] Out and about in Ottawa. hmmm... beer. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mc...@sa... http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys - custom hacks make this fully PGP2 compat iQCVAwUBP1jYQ4qHRg3pndX9AQEtSwQA7KjbmS24RfWnvO1z2bRBzjmmr/u2prXP q3bDmsEiS49oFA+00d/Q+pp2z9CIC6NWE2GOzK4VnMDoOXu48mDURUiZ+BhNdv0Y rwzqW0tJrBTrBeceLNZYtAU+hTUoEKrLDLcL44ihPEKxLqDkWjWBL2kEDyAgFMiJ P9n+/XjBWjo= =34L/ -----END PGP SIGNATURE----- |
From: Matt Z. <md...@de...> - 2003-09-05 18:49:26
|
On Fri, Sep 05, 2003 at 02:39:01PM -0400, Michael Richardson wrote: > >>>>> "Matt" == Matt Zimmerman <md...@de...> writes: > Matt> The fact that you said it broke _potato_'s mount, specifically, led > Matt> me to believe that newer versions did not do this (they do). > > Ah, so your fix basically breaks all distros? No. > I think that removing your patch is a better idea. Find another way to make > tar happy. I'm not motivated to put any more effort into helping you fix your problem. I already filed a patch for mount in the BTS. -- - mdz |
From: BlaisorBlade <bla...@ya...> - 2003-09-17 18:14:20
|
Alle 20:39, venerd=EC 5 settembre 2003, Michael Richardson ha scritto: > >> If you have a simple /sbin/mount that you can recommend that solves > >> my problem, I will consider using it. > > Matt> The fact that you said it broke _potato_'s mount, specifically, > led Matt> me to believe that newer versions did not do this (they do). > > Ah, so your fix basically breaks all distros? I have no idea. > Then clearly it needs to be fixed in the kernel, don't you think? > > Matt> However, the fix to mount is trivial, so you can easily create = an > Matt> /sbin/mount which should work. > > I think that removing your patch is a better idea. Find another way to > make tar happy. > > Booting the system is pretty important. I think that since anyway there is not a permission layer, you shouldn't bo= ot=20 off an hostfs filesystem. Mount with -o loop a new file, then copy all the= =20 filesystem content. Or maybe(but ask to other developers/check docs) if you= =20 have a whole partition, say ubd0=3D/dev/<your part> to UML. With hostfs,=20 anyway, if you don't run the guest with root privileges, files created by=20 root will be owned by the user running the Uml(i.e. it can happen that=20 everything works, especially if you login in the Uml only with a uid=3D<uid= of=20 Uml on the host>, but not everything will work), while root won't have acce= ss=20 to certain files(you can avoid also this, by not putting in that hierarchy= =20 any file of root from the host). =2D-=20 cat <<EOSIGN Paolo Giarrusso, aka Blaisorblade Linux Kernel 2.4.21/2.6.0-test on an i686; Linux registered user n. 292729 EOSIGN |