Some degree of unrealism in Ubuntu
|
| Author | Content |
|---|---|
| montezuma Dec 26, 2009 1:30 PM EDT |
The project was sold as "it just works" by Shuttleworth when it started. A lot of the time this has worked out but it is a bit unrealistic in the following way: Many problems that users experience can be traced to upstream bugs and the whole point about FOSS is that a project like Ubuntu has often little control over such things. You will often see bugs kicked upstream by devs on Launchpad and usually quite justifiably. The devs are on a 6 month treadmill so often have little time to submit patches upstream. They tend to prioritize what they fix and if your favourite app is not included you can get aggrieved. This happened to me recently with a camera. It certainly doesn't "just work" at present and after a launchpad excursion I found out the problem is with application developers who are not dealing with a new libgphoto2 API.
Ubuntu devs cannot sort all this out but then why did Shuttleworth oversell things to begin with? Bottomline is that the distro is pretty good overall modulo a few minor annoyances for me at least. It does not match the hype from Shuttleworth however. If it did then the Ubuntu forum would not be chockfull of frustrated newbies. |
| azerthoth Dec 26, 2009 4:07 PM EDT |
Sorry Steven, your whole article is based upon a faulty premise. Not only is Ubuntu not Linux, it's not a technically superior linux in any way you care to define it. Mandriva was doing better than Ubuntu is now with ease of use before the first Ubuntu shipped. From a configurability standpoint it can not even approach source based distro's. The only reason it took off like it did was because of the initial hype about shipping the CD for free. From any metric you care to approach it from other than fan boi user base, it is inferior in almost every aspect to many other linux out there. So the premise that Ubuntu is 'doing it right' is flawed from the start. |
| dthacker Dec 26, 2009 4:15 PM EDT |
Mark Shuttleworth's charisma and promises are not enough to get me to stay with OS that doesn't work well. I've stayed with Ubuntu because *for me* it works quite well with a minimum of fussing. Yes there is sometimes a PITA problem, but these problems almost always get dealt with in the next release. I don't think I was oversold, and I honestly don't see where Canonical or the LoCo's are overselling the product either. No one told me it was going to work 100% error free, 100% of the time. Even MS won't do that. That's why they have a EULA! Change is painful. That's why the Ubuntu forum is full of frustrated newbies. Dave |
| hkwint Dec 26, 2009 5:42 PM EDT |
Quoting:The only reason it took off like it did was because of the initial hype about shipping the CD for free. I don't agree, I think some company (Canonical) pushing Desktop Linux and Mandriva failing lately has something to do with it too. Quoting:OpenBSD, Slackware and Mepis are among the distros/projects that have a somewhat similar governance in which the buck stops with one person. Really? There's non-profit behind OpenBSD of which Theo de Raadt is no director, and apart from that it's always stressed as a 'team effort'. With Slackware, I can't find any non-profit / company behind it, nor can I find the names of a team of core-developers - such as is the case with OpenBSD. Ubuntu is just the product of the company, and just like any company there's some hierarchy and someone is at the top. I wouldn't consider that 'somewhat similar', but it depends on how much 'somewhat' is I guess. |
| Steven_Rosenber Dec 26, 2009 6:49 PM EDT |
I wonder if there are any Ubuntu contributors who don't work for Canonical who are feeling a bit squirrely about donating their time to a project run by a for-profit company. Not that Fedora and OpenSuse are any different, since they both feed into products sold for profit. Re: the OpenBSD foundation. I believe it's a bit new, and the project still encourages donations direct to Theo. The good thing about Theo and OpenBSD is that the development is all out there in the open, with the tree always accessible, lots of crosstalk on the mailing lists, releases every six months, no promises made and not kept. And just like Theo's disagreements with the NetBSD team prompted him to start his own project, so can anybody else who thinks differently. The thing about Ubuntu is that it's based on Debian, as well as all the upstream projects that go into it. I think people half-expect Ubuntu to get so big that it will increasingly do its own thing, make its own patches and roll its own distro with less Debian and more Ubuntu. The problem I pose is that it's not just Ubuntu contributing upstream, but rather whether upstream is interested in what Ubuntu is doing. It's an open question to which I have no answer. I'm only jumping off of Ubuntu at the moment because of all the breakage on my main system. I've had breakage in every distro/project, including Debian, and even in Ubuntu the trouble usually comes from upstream. So for me a slower cycle works at the moment, and that means not OpenBSD, not Ubuntu, not Fedora, but something like Debian or Slackware. Debian's just easier for me, so that's it. |
| hkwint Dec 26, 2009 7:53 PM EDT |
Indeed, there's a distinction between 'upstream' and 'Ubuntu', and I guess from a frame of reference of Ubuntu, Debian might also be upstream.
It's this distinction that causes some of the problems and sometimes angry people I suggest (when talking about Debian, planning also is a problem it seems). Take F/N/OBSD. They choose a set of software considered part of their OS, and then, when there's a bug in sendmail, ftp, pgk_add or something else considered part of their OS they fix it themselves. Most of the times - in contrary to one particular example with Debian - BSD people seem to know what they're changing. If the people at Ubuntu find some bug in senmail, ftp or apt-get they might 'redirect' to upstream. But 'upstream' might receive bug reports from many distro's. Probably it's because a base-install of Ubuntu is much larger and complexer than a base install of F/N/O-BSD - and I guess they don't have the expertise. Otherwise I'd wonder why they just don't make their own OS instead of 'just' a distribution, and just take care of anything in the base install themselves. |
| tuxtom Dec 27, 2009 7:22 PM EDT |
Quoting:Not only is Ubuntu not Linux, it's not a technically superior linux in any way you care to define it.My Linux is better than your Linux. |
| azerthoth Dec 28, 2009 2:39 AM EDT |
tuxtom, this is not an opinion, although if you believe you can refute it with facts that I am unaware of I will be happy to discuss it. |
| tracyanne Dec 28, 2009 3:12 AM EDT |
At last http://www.hackinglinuxexposed.com/articles/20031214.html this explains something that has always concerned me about the single partition that is the default for Ubuntu. Quoting:Now anyone can make a hard link or symlink, assuming they have write permission to a directory. While symlinks can cross filesystem boundaries (they point to file names, not inodes) a hard link can only be created on the filesystem where the target file resides. |
| gus3 Dec 28, 2009 3:14 AM EDT |
@az: I think that's his point. |
| gus3 Dec 28, 2009 3:30 AM EDT |
@tracyanne: Holy cow. I just tested that, and... epic fail? Without root, in a writable directory, I can create a hard link to a root-owned file, which I then cannot delete. Here's the session: Quoting:gus3@paul:~$ cd /var/tmp gus3@paul:/var/tmp$ ln /sbin/ss ./ss gus3@paul:/var/tmp$ stat ss File: `ss' Size: 66880 Blocks: 144 IO Block: 4096 regular file Device: 803h/2051d Inode: 565493 Links: 2 Access: (0755/-rwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2009-09-18 20:30:23.000000000 -0400 Modify: 2009-06-17 14:55:57.000000000 -0400 Change: 2009-12-28 02:25:21.278349664 -0500 gus3@paul:/var/tmp$ rm ss rm: remove write-protected regular file `ss'? y rm: cannot remove `ss': Operation not permitted gus3@paul:/var/tmp$Why was I able to increment, but not decrement, the reference count on a file to which I had no write access? Addendum: I should point out, I'm using 64-bit Slackware Linux, not Ubuntu. |
| tracyanne Dec 28, 2009 3:32 AM EDT |
@gus, can you delete the file as root? |
| gus3 Dec 28, 2009 3:36 AM EDT |
@ta: Yes. |
| tracyanne Dec 28, 2009 3:45 AM EDT |
can you then access it using the hard link |
| gus3 Dec 28, 2009 3:46 AM EDT |
Yes. |
| tracyanne Dec 28, 2009 3:47 AM EDT |
I've just tested it. I have a seperate home partition., and I certainly can't create a hard link across partitions, I can create a soft link though. If I create a hard link within the same partition, I can delete the file and still access the file via the hard link. Here's what I did. As root, I copied a text file "qwerty" to /bin cp /home/tracy/qwerty /bin I then attempted to hard link to it as tracy in my home directory tracy@annie:~$ ln /bin/qwerty /home/tracy/qwertylink ln: creating hard link `/home/tracy/qwertylink' => `/bin/qwerty': Invalid cross-device link tracy@annie:~$ and got the above error. the following works fine tracy@annie:~$ ln -s /bin/qwerty /home/tracy/qwertylink tracy@annie:~$ ls qwertylink qwertylink tracy@annie:~$ As root I can run root@annie:/root# ln /bin/qwerty /root/qwertylink root@annie:/root# ls qwertylink qwertylink root@annie:/root# and it works fine, creating ahardlink. attempting the same thing into /home/tracy as root does not root@annie:/root# ln /bin/qwerty /home/tracyr/qwertylinkr ln: creating hard link `/home/tracyr/qwertylinkr' => `/bin/qwerty': No such file or directory root@annie:/root# So it is not possible to to create a hard link across filesystems. now I can read the file /bin/qwerty from my home directory using the soft link, and I can read the file from the root user directory using the hard link. But if I delete the file /bin/qwerty root@annie:/bin# rm /bin/qwerty root@annie:/bin# ls qwerty ls: cannot access qwerty: No such file or directory root@annie:/bin# and I attempt to read the file using the soft link in /home/tracy tracy@annie:~$ cat qwertylink cat: qwertylink: No such file or directory tracy@annie:~$ ls qwertylink qwertylink the link is still there. but the file it links to has gone. but if I attempt the same things as root using the hardlink. root@annie:/root# cat qwertylink chapter{Bc,sfsd fsdfhjgdsjf gjhfdg}chapter{} root@annie:/root# if displays the contents of the now non existent file. root@annie:/root# ls /bin/qwerty ls: cannot access /bin/qwerty: No such file or directory root@annie:/root# So as the article describes, the inode continues to exist for as long as the hardlink exists, even if you create a new copy of the file. root@annie:/bin# cp /home/tracy/qwerty /bin root@annie:/bin# cat /bin/qwerty chapter{Bc,sfsd fsdfhjgdsjf gjhfdg}chapter{} chapter{Bc,sfsd fsdfhjgdsjf gjhfdg}chapter{}chapter{Bc,sfsd fsdfhjgdsjf gjhfdg}chapter{}chapter{Bc,sfsd fsdfhjgdsjf gjhfdg}chapter{}chapter{Bc,sfsd fsdfhjgdsjf gjhfdg}chapter{}chapter{Bc,sfsd fsdfhjgdsjf gjhfdg}chapter{} root@annie:/root# cat qwertylink chapter{Bc,sfsd fsdfhjgdsjf gjhfdg}chapter{} root@annie:/root# as you can see the hardlink in /root is still displaying the contents of the deleted file. |
| gus3 Dec 28, 2009 3:51 AM EDT |
@ta: 1. What kernel version? 2. Create hard link to root-owned file, without root privileges? 3. Delete said hard link, without root privileges? |
| tracyanne Dec 28, 2009 4:31 AM EDT |
1. What kernel version? 2.6.31-17-generic (Ubuntu) 2. Create hard link to root-owned file, without root privileges? root@annie:/bin# cp /xorg.conf.new /home/tracy root@annie:/bin# ls /home/tracy/xorg.conf.new /home/tracy/xorg.conf.new root@annie:/bin# tracy@annie:~$ ln xorg.conf.new lin2rootowned tracy@annie:~$ ls link2rootowned ls: cannot access link2rootowned: No such file or directory tracy@annie:~$ ls lin2rootowned lin2rootowned tracy@annie:~$ cat lin2rootowned Section "ServerLayout" Identifier "X.org Configured" Screen 0 "Screen0" 0 0 InputDevice "Mouse0" "CorePointer" InputDevice "Keyboard0" "CoreKeyboard" Viewport 0 0 Depth 24 ....removed to reduce size of posting .... EndSubSection EndSection 3. Delete said hard link, without root privileges? tracy@annie:~$ rm xorg.conf.new rm: remove write-protected regular file `xorg.conf.new'? y tracy@annie:~$ ls xorg.conf.new ls: cannot access xorg.conf.new: No such file or directory tracy@annie:~$ cat lin2rootowned Section "ServerLayout" Identifier "X.org Configured" Screen 0 "Screen0" 0 0 InputDevice "Mouse0" "CorePointer" InputDevice "Keyboard0" "CoreKeyboard" .....removed to reduce size of post EndSubSection EndSection tracy@annie:~$ As you can see the hardlink can be created so long as the file and the hardlink are in the same filesystem, and the inode remains intact so long as the hardlink exists. |
| krisum Dec 28, 2009 5:40 AM EDT |
Quoting: At last [HYPERLINK@www.hackinglinuxexposed.com] this explains something that has always concerned me about the single partition that is the default for Ubuntu.All linux distributions have many user writable directories (/tmp, /var/tmp, /var/lock, /var/spool/samba) besides /home and no one places all these on separate partitions to avoid the mentioned vulnerability. Besides if the suid program was used to compromise the system, it stands to reason that the attacker can make copies etc. even across filesystems. If anything one would rather say that this is a hole in "ln". |
| tracyanne Dec 28, 2009 8:25 AM EDT |
@krisum, read the article, read what I did to demonstrate. |
| krisum Dec 28, 2009 11:06 AM EDT |
@tracyanne, I have read both. Read my comment again. |
| gus3 Dec 28, 2009 1:23 PM EDT |
@tracyanne: Okay, I tried your approach, and got your results. Try hard-linking a root-owned file in /sbin to something in /var/tmp, and see if you get my "create, but not delete" results. So now, the big questions seem to be: 1. Why, in certain circumstances (yet-to-be determined), can an EUID without write access to an inode, create and remove references to it? 2. Why, in other circumstances, can an EUID without write access to an inode, create but not remove references to it? 3. What is/are the circumstance(s) to make the difference? |
| tracyanne Dec 28, 2009 6:37 PM EDT |
@krisum, you missed the point. It wasn't about user writeable directories. It was about Inodes staying active while there is a hardlink to the file that has been deleted, and the danger that potentially creates when there is a a single filesystem. the point was it is possible to open up the system to an attacker, by not removing the hardlinks, not what an attacker might be able do once they are in. Ubuntu attempts to mitigate this by providing the user with the ability to create soft links, the "Create a Link" in the right mouse click menu. But that only works by assuming the user will never experiment with ln, remains ignorant of the commandline, and never uses the commandline. Not a likely prospect given the amount of advice in the ubuntu forums to "sudo something or another". It's security by obscurity. Yes there probably is something wrong that needs fixing, but "ln" is doing exactly what it was designed to do, so I can't see that there is a bug there. Maybe there needs to be a system change in the way "ln" is used, maybe hardlinks should only be available to "root", and even the "adinistrator" group in suid should be excluded to stop the type of user Ubuntu are attempting stop, from using hard links. |
| krisum Dec 28, 2009 11:37 PM EDT |
@tracyanne
Quoting: you missed the point. It wasn't about user writeable directories. It was about Inodes staying active while there is a hardlink to the file that has been deleted, and the danger that potentially creates when there is a a single filesystem. the point was it is possible to open up the system to an attacker, by not removing the hardlinks, not what an attacker might be able do once they are in.Exactly, and that is why the real issue is user writable directories. If there are no user writable directories (edit: I mean in the same partition where suid programs reside) then an attacker cannot create hard-links in the first place to suid programs (though as I mentioned this point is likely to be moot if the system has been compromised) -- notice that for non-suid programs this does not matter in any case since a hard-link is functionally equivalent to a cp from attacker's POV. So what if an attacker makes a copy so that there is a supposedly vulnerable version still around? If someone were to make a copy of "apache", for example, it does not matter since the system will not be executing it during init etc -- it is completely a users binary which works such. Why do you think that a vulnerable version of "apache", for example, in user's home directory is a security hole? Of course, if the user were to run it explicitly then it might be a problem just like for any other vulnerable binaries in user's home. You are completely missing the point that the real problem is with suid programs. That is why the site makes an oblique reference to it in second recommendation "If they ran suid program scanners, they would have picked up this 'new' suid program" but does not make this point sufficiently clear. One of the recommendations that the site mentions is to have user writable directories /home, /tmp, /var/tmp on separate partitions, but as I mentioned a typical linux installation will have many more user writable directories and no distro I know of will offer separate partitions by default for all of those. Quoting: Ubuntu attempts to mitigate this by providing the user with the ability to create soft links, the "Create a Link" in the right mouse click menu.No no, this has got to do nothing with Ubuntu or soft-links -- see above. Quoting: Yes there probably is something wrong that needs fixing, but "ln" is doing exactly what it was designed to do, so I can't see that there is a bug there.If permission-wise "ln" were to behave like "cp" then users cannot create hard-links to programs having suid bit still set. edit: Also notice that if one were to replace a file with a new version using normal "cp" then all hard-links will also point to the new version. The problem will only be if one were to first remove the old file and then add the new file in the same place. Apt and other installers will normally do the former so there is no vulnerability in any case in the normal course of actions. |
| tracyanne Dec 29, 2009 1:41 AM EDT |
gus I get the same results as you. root@annie:/sbin# cp /home/tracy/qwerty /sbin/qwerty root@annie:/sbin# tracy@annie:~$ cd /var/tmp tracy@annie:/var/tmp$ ln /sbin/qwerty qwertylink tracy@annie:/var/tmp$ ls qwertylink qwertylink tracy@annie:/var/tmp$ cat qwertylink chapter{Bc,sfsd fsdfhjgdsjf gjhfdg}chapter{} chapter{Bc,sfsd fsdfhjgdsjf gjhfdg}chapter{}chapter{Bc,sfsd fsdfhjgdsjf gjhfdg}chapter{}chapter{Bc,sfsd fsdfhjgdsjf gjhfdg}chapter{}chapter{Bc,sfsd fsdfhjgdsjf gjhfdg}chapter{}chapter{Bc,sfsd fsdfhjgdsjf gjhfdg}chapter{} tracy@annie:/var/tmp$ rm /sbin/qwerty rm: remove write-protected regular file `/sbin/qwerty'? y rm: cannot remove `/sbin/qwerty': Permission denied tracy@annie:/var/tmp$ rm qwertylink rm: remove write-protected regular file `qwertylink'? y rm: cannot remove `qwertylink': Operation not permitted tracy@annie:/var/tmp$ root@annie:/sbin# rm /var/tmp/qwertylink root@annie:/sbin# rm /sbin/qwerty root@annie:/sbin# |
| krisum Dec 29, 2009 2:50 AM EDT |
@gus3
Quoting: 1. Why, in certain circumstances (yet-to-be determined), can an EUID without write access to an inode, create and remove references to it?If the user has write permissions for the target directory e.g. /var/tmp or /home. For creating links the permissions of the source do not matter (holds for both hard-links and symlinks). It only comes into play when using that link. Quoting: 2. Why, in other circumstances, can an EUID without write access to an inode, create but not remove references to it?Because /var/tmp or /tmp have sticky perms (1777) so only the user owning a file/link can remove that file/link. However, if the user has normal write perms like in /home/user or any directory without sticky bit then remove will be fine just for any other normal files. The ownership of symlink itself is stored separately while for a hardlink it is the same as that of the source. |
| gus3 Dec 29, 2009 4:08 AM EDT |
@krisum: That's the scenario I was starting to see in my mind's eye. According to my research, it's been that way for a long time in Unix, and Linux seems to have carried on with that "tradition." The problem (with security implications) is that, unlike the inode permissions, the inode reference count is not subject to the effective UID of a process. ...which leads to the next question: What are the implications of restricting reference count alterations to the permissions on the inode? Or, more succinctly, "why can someone without write permission on a file create a hard link to it?" Sadly, the materials available to me do not explain this. |
| krisum Dec 30, 2009 12:35 AM EDT |
Quoting: Or, more succinctly, "why can someone without write permission on a file create a hard link to it?"That holds for copy too i.e. someone without write permission on a file can certainly create a copy of it as long as the user has write permissions on the target directory. However, the copy comes with permissions of the user as against that of the source as in hardlink. I think that if "ln" were to behave more like "cp" especially for suid programs, then security-wise it will be okay (alternatively just disallow creating hardlinks to suid programs if having own permissions for hardlink is not possible). I guess linux would be following the POSIX specifications in this. No idea of the implications of this change though. |
| gus3 Dec 30, 2009 1:42 AM EDT |
Copying doesn't alter the file metadata, except (perhaps) the atime. I had a blurb here about removing read permissions on programs, but a quick test revealed that unreadable files can't be dlopen()'ed, and dynamic linking fails. Funnily enough, removing execute permissions doesn't inhibit dynamic linking. It's times like this that I remind myself it's all ones and zeros, and their meaning depends entirely on the context. Sigh. |
| krisum Dec 30, 2009 3:03 AM EDT |
Quoting: Copying doesn't alter the file metadata, except (perhaps) the atime.Certainly changes the owner and suid bits. |
| gus3 Dec 30, 2009 2:26 PM EDT |
Not on the original. |
Posting in this forum is limited to members of the group: [ForumMods, SITEADMINS, MEMBERS.]
Becoming a member of LXer is easy and free. Join Us!