[Bug 257093] [NEW] tmpreaper should automatically avoid /tmp/aquota.{user, group}
Public bug reported:
The old quota file format used quota.* names. These names have explicit
protection in tmpreaper's /etc/cron.daily file.
However, the new quota files have a different name. They're named
aquota.*. These are just as important as the older quota-prefixed files.
** Affects: tmpreaper (Ubuntu)
Importance: Undecided
Status: New
--
tmpreaper should automatically avoid /tmp/aquota.{user,group}
https://bugs.launchpad.net/bugs/257093
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 257093] Re: tmpreaper should automatically avoid /tmp/aquota.{user, group}
** Attachment added: "Patch for (installation path) /etc/cron.daily/tmpreaper"
http://launchpadlibrarian.net/16713158/tmpreaper-aquota.patch
--
tmpreaper should automatically avoid /tmp/aquota.{user,group}
https://bugs.launchpad.net/bugs/257093
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 258369] [NEW] mailagent package has wrong version number (3.73 should be 3.0.73)
Public bug reported: Binary package hint: mailagent Mailagent has an incorrect package version. In aptitude it reports itself as: 3.73-26, however mailagent -V reports: mailagent 3.0 PL73 PL appears to stand for "patch level" which seems to imply it should actually be 3.0.73. This is corroborated by the copyright file stating: It may also be found at most of the Comprehensive Perl Archive Network sites, in the location <$CPAN/authors/id/RAM/[EMAIL PROTECTED]>. If you go to http://search.cpan.org/~ram/ (as the CPAN referenced author ID 'RAM') you see no trace of a mailagent-3.73. Instead you see: mailagent-3.0.73 It would seem there is no mailagent-3.73 released. The version number is way off, particularly if Raphael Manfredi decides to release a mailagent 3.1 at some point. An "epoch version" can, and should, be used to correct the version number issue. This would make the next version, according to the debian/changelog file: 1:3.0.73-1 Cheers, Steven Black ** Affects: mailagent (Ubuntu) Importance: Undecided Status: New -- mailagent package has wrong version number (3.73 should be 3.0.73) https://bugs.launchpad.net/bugs/258369 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 234409] [NEW] friendly-recovery violates the Linux Filesystem Hierarchy Standard
Public bug reported: Binary package hint: friendly-recovery friendly-recovery uses files in /usr, but runs in single-user mode. This is a violation of the Linux Filesystem Hierarchy Standard, which states that "The contents of the root filesystem must be adequate to boot, restore, recover, and/or repair the system." (See http://www.pathname.com/fhs/pub/fhs-2.3.html#PURPOSE2 ) friendly-recovery, due to the current install locations: (1) prevents the system from booting in recovery mode if the /usr partition is corrupted. (2) prevents /usr from being resized, as it can never be unmounted I'm a fan of LVM, and found #2 a huge problem for me. A huge benefit of LVM is that it allows you to dynamically increase the size of partitions. This benefit is negated if you can't unmount some of your partitions due to software using it. ** Affects: friendly-recovery (Ubuntu) Importance: Undecided Status: New -- friendly-recovery violates the Linux Filesystem Hierarchy Standard https://bugs.launchpad.net/bugs/234409 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 234409] Re: friendly-recovery violates the Linux Filesystem Hierarchy Standard
My preference: Instead of /usr/share, the recovery menu logic moves to /lib. Either whiptail needs to also move to /bin, or you need to fall-back to a shell-based solution if whiptail is unavailable (such as the partition not available). -- friendly-recovery violates the Linux Filesystem Hierarchy Standard https://bugs.launchpad.net/bugs/234409 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 234421] [NEW] single-user mode should work when libraries are broken
Public bug reported: Binary package hint: friendly-recovery It would be great if the recovery-menu project could add a static- compiled stub that tries to run the recovery-menu with bash, and if that fails it would try to fall back to a known static-compiled shell (such as sash, busybox-static, or bash-static) then falling back to /sbin/sulogin if nothing else is available. In my opinion, attempting to fall-back to a static-compiled shell before falling back to sulogin does not significantly present any greater security concern. The Ubuntu default is to have the root password locked out, and administrators which like security will know that the best way to protect single-user mode is to add a GRUB-based password, as that retains the security of having the root account locked out. With the default installation of recovery-menu, Ubuntu has moved in a direction requiring boot-loader security to prevent the system from being manipulated in single-user mode. (With just the three options now available, it may be possible for a person to "fix" another person's X configuration to something unexpected.) Additionally, with the recovery-menu logic automatically falling back to a staticly compiled shell, we can hopefully avoid static shell packages shadowing the root account to create a "root account with a static shell", like sash does with the "sashroot" account in hardy. ** Affects: friendly-recovery (Ubuntu) Importance: Undecided Status: New -- single-user mode should work when libraries are broken https://bugs.launchpad.net/bugs/234421 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 234434] [NEW] sash creates 'sashroot' account
*** This bug is a security vulnerability *** Public security bug reported: Binary package hint: friendly-recovery When you install sash it clones your root account to create a 'sashroot' account. This is useless with Ubuntu, as Ubuntu has root's account locked out. This means sash is cloning a locked out acount, which does no one any good. Additionally, on systems with root account passwords, this is a security concern. Root account passwords are serious business, and they regularly should be changed. By cloning the password, you are effectively by- passing the normal processes in place in an institution to regulate the root password. As an example: Company A has a system administrator, Evil-Bill. Now, Evil-Bill knows the institution will change the root passwords on all the systems when he leaves. He also knows that packages are not strictly watched. (How many places actually strictly monitor packages and the user accounts they each create?) Before he leaves, he installs 'sash'. They change all the root accounts, but they miss his backdoor account 'sashroot'. A few weeks after he has left, he logs in and performs his evil. Note that this security concern occurs on Ubuntu systems in cases where the administrator thought that creating a password for the root user increased security of single-user mode, or in cases where administrative policy at an institution requires setting/changing the root password on a regular basis. Another solution to the problem addressed by creating the 'sashroot' account would be to use standard package logic to ask the user if their root/single-user sessions should use a potentially more reliable staticly compiled shell. Then all packages providing static shells should offer alternatives. A name such as /bin/static-sh could be used as the common alternative name. Then with the root account set to /bin/static-sh, things should just work. (You could go as far as making /bin/bash a super-low recommendation for /bin/static-sh, so that if things didn't get cleared up properly when all the static shells were removed, the root account would still be accessable.) ** Affects: sash (Ubuntu) Importance: Undecided Status: New ** Visibility changed to: Public -- sash creates 'sashroot' account https://bugs.launchpad.net/bugs/234434 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 234434] Re: sash creates 'sashroot' account
Correcting the package this affects. ** Changed in: sash (Ubuntu) Sourcepackagename: friendly-recovery => sash -- sash creates 'sashroot' account https://bugs.launchpad.net/bugs/234434 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 234434] Re: sash creates 'sashroot' account
I wanted to add that when sash is purged, it does not remove the sashroot account. -- However the shell gets changed to bash. This means that if packages are being monitored by regular daily reports pulled from a dpkg -l list, you can get around this showing up in logs by installing sash and immediately purging sash. -- sash creates 'sashroot' account https://bugs.launchpad.net/bugs/234434 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 368127] Re: ToME Crashes Randomly
I ran across this bug report when I was experiencing a very similar problem -- one which I think Adam may be experiencing. Adam, is it really crashing randomly, or does it reliably crash when you try to save the game? When it crashed via saving the game, it will likely leave a save-file around which will also crash if you try to load it. If that's the problem you're encountering, then it is the same problem I've been having. That problem has been reported upstream, and upstream has a patch: http://wiki.t-o-m-e.net/BugReport930 I can confirm that after applying the patch on that page, I can save new games. The old partially-saved games (from earlier attempts to save the game) are a total waste and need to be removed. The way to check (and remove the crap that won't load) is simple: If the game saved properly, it should show up in the list of saved games (on the "New Character"/"Load Character" screen). The saved files are placed in "~/.tome/2.3/save/". The bogus files show up in pairs, like: PLAYER.new PLAYER.pnc -- PLAYER (the default save file name) isn't usable until these two files are removed. Proper save files will have no extension (just PLAYER) with an additional user.$UID.svg descriptor file (appears to be one-line per save file, or per character -- I'm not sure. $UID is my system user-id). I'd love to see this patch rolled in, as the game is extremely frustrating without it. A new player starts a new game, has a great time. tries to save the game, and *poof* -- the game is lost. As the URL says, this bug is more visible on Ubuntu systems due to the use of Fortify. This particular bug wouldn't cause memory corruption until the user saves and that usually happens at application termination -- it is quite possible that folks not using Fortify would have never noticed the bug. The upstream folks are also working on 3.0. We need this patch. -- ToME Crashes Randomly https://bugs.launchpad.net/bugs/368127 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 368127] Re: ToME Crashes Randomly
It looks like wiki.t-o-m-e.net is currently off-line. Worst case this patch should be easy to recreate. There's a buffer overflow in the save-game logic. Since it only happened saving the game, and most folks save the game before they quit, folks never noticed the buffer overflow... until Valgrind became the default with Ubuntu. If you build the code from source (with debugging symbols) and run gdb on it it should point you to the source of the error. To reproduce the problem all you need to do is create a new game and try to immediately save it. I've had some issues with some of my hardware since I commented on this ticket and I'm fairly certain I no longer have the original patch on any of my systems. This should be a straight-forward process, so I'm going to try it myself and whip up a patch. -- ToME Crashes Randomly https://bugs.launchpad.net/bugs/368127 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 368127] Re: ToME Crashes Randomly
Okay. I'm not sure how similar this is to the original patch, but the following three line patch takes care of the issue. There may be some other consequence of this. I didn't increase the buffer so it is getting truncated, but I don't see it. I'm just using strncpy instead of strcpy to make sure we don't write too much. I also explicitly set the last character of the array to be a NUL byte so it remains terminated even if it hits the limit. It worked with my test on Ubuntu 10.04, but it was a fairly quick test. Again, this fixes total breakage of this package in Ubuntu so this patch, the original patch, or a similar patch should be rolled in. The game is frustratingly unusable without a fix for this bug. ** Patch added: "tome-savefix.patch" http://launchpadlibrarian.net/52403339/tome-savefix.patch -- ToME Crashes Randomly https://bugs.launchpad.net/bugs/368127 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
