| 2014-10-29 14:50:51 |
Jamie Strandboge |
bug |
|
|
added bug |
| 2014-10-29 14:52:14 |
Jamie Strandboge |
description |
Symptoms are that cache files in /var/cache/apparmor and profiles in /var/lib/apparmor/profiles are sometimes corrupted after a reboot. We've already fixed several bugs in the apparmor and click-apparmor and made both more robust in the face of corruption, but we've still not found the cause.
The investigation is ongoing and this may not be a problem with the kernel at all, so this bug may be retargeted to another project.
The security team and the kernel team have discussed this a lot and Colin is currently looking at this. This bug is just so it can be tracked. Here is an excerpt from my latest email to Colin:
"I believe I have conclusively ruled out apparmor_parser and aa-clickhook by creating a new 'home/bug/test-with-true.sh'. Here is the test output:
http://paste.ubuntu.com/8648109/
Specifically, home/bug/test-with-true.sh changes the interesting parts of the algorithm to:
1. wait for unity8 to start (this ensures the apparmor upstart job is finished)
2. restore apparmor_parser and aa-clickhook, if needed
3. if /home/bug/profiles... exists, perform a diff -Naur /home/bug/profiles...
/var/lib/apparmor/profiles and fail if differences (note, apparmor_parser
and aa-clickhook were /bin/true during boot so they could not have changed
/var/lib/apparmor/profiles)
4. verify the profiles, exit with error if they do not
5. alternately upgrade/downgrade the packages
6. verify the profiles, exit with error if they do not
7. copy the known good profiles in the previous step to /home/bug/profiles...
8. have apparmor_parser and aa-clickhook point to /bin/true
9. reboot
10. go to step 1
In the paste you'll notice that in step 6 the profiles were successfully created by the installation of the packages, then verified, then copied aside, then apparmor_parser and aa-clickhook diverted, then rebooted, only to have the profiles in /var/lib/apparmor/profiles be different than what was copied aside. It would be nice to verify on your device as well (I reproduced several times here) and verify the reproducer algorithm. I think this suggests this is a kernel issue and not userspace.
IMPORTANT: you will want to update the reproducer and refollow all of these steps (ie, I updated the scripts, the debs, the sudoers file, etc):
$ wget http://people.canonical.com/~jamie/cking/aa-corruption.tar.gz
$ tar -zxvf ./aa-corruption.tar.gz
...
$ adb push ./aa-corruption.tar.gz /tmp
$ adb shell
phablet@ubuntu-phablet:~$ cd /tmp
phablet@ubuntu-phablet:~$ tar -zxvf ./aa-corruption.tar.gz
phablet@ubuntu-phablet:~$ sudo mount -o remount,rw /
phablet@ubuntu-phablet:~$ sudo cp ./aa-corruption/etc/sudoers.d/phablet
/etc/sudoers.d/
phablet@ubuntu-phablet:~$ sudo mount -o remount,ro /
phablet@ubuntu-phablet:~$ sudo cp -a ./aa-corruption/home/bug /home
phablet@ubuntu-phablet:~$ exit
$ cd ./aa-corruption
$ ./test-from-host.sh
...
The old script is still in place. Simply adjust ./test-from-host.sh to have:
testscript=/home/bug/test.sh
#testscript=/home/bug/test-with-true.sh" |
Symptoms are that cache files in /var/cache/apparmor and profiles in /var/lib/apparmor/profiles are sometimes corrupted after a reboot. We've already fixed several bugs in the apparmor and click-apparmor and made both more robust in the face of corruption, but we've still not found the cause.
The investigation is ongoing and this may not be a problem with the kernel at all, so this bug may be retargeted to another project.
The security team and the kernel team have discussed this a lot and Colin is currently looking at this. This bug is just so it can be tracked. Here is an excerpt from my latest email to Colin:
"I believe I have conclusively ruled out apparmor_parser and aa-clickhook by creating a new 'home/bug/test-with-true.sh'. Here is the test output:
http://paste.ubuntu.com/8648109/
Specifically, home/bug/test-with-true.sh changes the interesting parts of the algorithm to:
1. wait for unity8 to start (this ensures the apparmor upstart job is finished)
2. restore apparmor_parser and aa-clickhook, if needed
3. if /home/bug/profiles... exists, perform a diff -Naur /home/bug/profiles...
/var/lib/apparmor/profiles and fail if differences (note, apparmor_parser
and aa-clickhook were /bin/true during boot so they could not have changed
/var/lib/apparmor/profiles)
4. verify the profiles, exit with error if they do not
5. alternately upgrade/downgrade the packages
6. verify the profiles, exit with error if they do not
7. copy the known good profiles in the previous step to /home/bug/profiles...
8. have apparmor_parser and aa-clickhook point to /bin/true
9. reboot
10. go to step 1
In the paste you'll notice that in step 6 the profiles were successfully created by the installation of the packages, then verified, then copied aside, then apparmor_parser and aa-clickhook diverted, then rebooted, only to have the profiles in /var/lib/apparmor/profiles be different than what was copied aside. It would be nice to verify on your device as well (I reproduced several times here) and verify the reproducer algorithm. I think this suggests this is a kernel issue and not userspace.
IMPORTANT: you will want to update the reproducer and refollow all of these steps (ie, I updated the scripts, the debs, the sudoers file, etc):
$ wget http://people.canonical.com/~jamie/cking/aa-corruption.tar.gz
$ tar -zxvf ./aa-corruption.tar.gz
...
$ adb push ./aa-corruption.tar.gz /tmp
$ adb shell
phablet@ubuntu-phablet:~$ cd /tmp
phablet@ubuntu-phablet:~$ tar -zxvf ./aa-corruption.tar.gz
phablet@ubuntu-phablet:~$ sudo mount -o remount,rw /
phablet@ubuntu-phablet:~$ sudo cp ./aa-corruption/etc/sudoers.d/phablet
/etc/sudoers.d/
phablet@ubuntu-phablet:~$ sudo mount -o remount,ro /
phablet@ubuntu-phablet:~$ sudo cp -a ./aa-corruption/home/bug /home
phablet@ubuntu-phablet:~$ exit
$ cd ./aa-corruption
$ ./test-from-host.sh
...
The old script is still in place. Simply adjust ./test-from-host.sh to have:
testscript=/home/bug/test.sh
#testscript=/home/bug/test-with-true.sh"
The kernel team has been able to confirm the symptoms. |
|
| 2014-10-29 14:57:25 |
Jamie Strandboge |
description |
Symptoms are that cache files in /var/cache/apparmor and profiles in /var/lib/apparmor/profiles are sometimes corrupted after a reboot. We've already fixed several bugs in the apparmor and click-apparmor and made both more robust in the face of corruption, but we've still not found the cause.
The investigation is ongoing and this may not be a problem with the kernel at all, so this bug may be retargeted to another project.
The security team and the kernel team have discussed this a lot and Colin is currently looking at this. This bug is just so it can be tracked. Here is an excerpt from my latest email to Colin:
"I believe I have conclusively ruled out apparmor_parser and aa-clickhook by creating a new 'home/bug/test-with-true.sh'. Here is the test output:
http://paste.ubuntu.com/8648109/
Specifically, home/bug/test-with-true.sh changes the interesting parts of the algorithm to:
1. wait for unity8 to start (this ensures the apparmor upstart job is finished)
2. restore apparmor_parser and aa-clickhook, if needed
3. if /home/bug/profiles... exists, perform a diff -Naur /home/bug/profiles...
/var/lib/apparmor/profiles and fail if differences (note, apparmor_parser
and aa-clickhook were /bin/true during boot so they could not have changed
/var/lib/apparmor/profiles)
4. verify the profiles, exit with error if they do not
5. alternately upgrade/downgrade the packages
6. verify the profiles, exit with error if they do not
7. copy the known good profiles in the previous step to /home/bug/profiles...
8. have apparmor_parser and aa-clickhook point to /bin/true
9. reboot
10. go to step 1
In the paste you'll notice that in step 6 the profiles were successfully created by the installation of the packages, then verified, then copied aside, then apparmor_parser and aa-clickhook diverted, then rebooted, only to have the profiles in /var/lib/apparmor/profiles be different than what was copied aside. It would be nice to verify on your device as well (I reproduced several times here) and verify the reproducer algorithm. I think this suggests this is a kernel issue and not userspace.
IMPORTANT: you will want to update the reproducer and refollow all of these steps (ie, I updated the scripts, the debs, the sudoers file, etc):
$ wget http://people.canonical.com/~jamie/cking/aa-corruption.tar.gz
$ tar -zxvf ./aa-corruption.tar.gz
...
$ adb push ./aa-corruption.tar.gz /tmp
$ adb shell
phablet@ubuntu-phablet:~$ cd /tmp
phablet@ubuntu-phablet:~$ tar -zxvf ./aa-corruption.tar.gz
phablet@ubuntu-phablet:~$ sudo mount -o remount,rw /
phablet@ubuntu-phablet:~$ sudo cp ./aa-corruption/etc/sudoers.d/phablet
/etc/sudoers.d/
phablet@ubuntu-phablet:~$ sudo mount -o remount,ro /
phablet@ubuntu-phablet:~$ sudo cp -a ./aa-corruption/home/bug /home
phablet@ubuntu-phablet:~$ exit
$ cd ./aa-corruption
$ ./test-from-host.sh
...
The old script is still in place. Simply adjust ./test-from-host.sh to have:
testscript=/home/bug/test.sh
#testscript=/home/bug/test-with-true.sh"
The kernel team has been able to confirm the symptoms. |
Symptoms are that cache files in /var/cache/apparmor and profiles in /var/lib/apparmor/profiles are sometimes corrupted after a reboot. We've already fixed several bugs in the apparmor and click-apparmor and made both more robust in the face of corruption, but we've still not found the cause.
The investigation is ongoing and this may not be a problem with the kernel at all, so this bug may be retargeted to another project.
The security team and the kernel team have discussed this a lot and Colin is currently looking at this. This bug is just so it can be tracked. Here is an excerpt from my latest email to Colin:
"I believe I have conclusively ruled out apparmor_parser and aa-clickhook by creating a new 'home/bug/test-with-true.sh'. Here is the test output:
http://paste.ubuntu.com/8648109/
Specifically, home/bug/test-with-true.sh changes the interesting parts of the algorithm to:
1. wait for unity8 to start (this ensures the apparmor upstart job is finished)
2. restore apparmor_parser and aa-clickhook, if needed
3. if /home/bug/profiles... exists, perform a diff -Naur /home/bug/profiles...
/var/lib/apparmor/profiles and fail if differences (note, apparmor_parser
and aa-clickhook were /bin/true during boot so they could not have changed
/var/lib/apparmor/profiles)
4. verify the profiles, exit with error if they do not
5. alternately upgrade/downgrade the packages
6. verify the profiles, exit with error if they do not
7. copy the known good profiles in the previous step to /home/bug/profiles...
8. have apparmor_parser and aa-clickhook point to /bin/true
9. reboot
10. go to step 1
In the paste you'll notice that in step 6 the profiles were successfully created by the installation of the packages, then verified, then copied aside, then apparmor_parser and aa-clickhook diverted, then rebooted, only to have the profiles in /var/lib/apparmor/profiles be different than what was copied aside. It would be nice to verify on your device as well (I reproduced several times here) and verify the reproducer algorithm. I think this suggests this is a kernel issue and not userspace.
IMPORTANT: you will want to update the reproducer and refollow all of these steps (ie, I updated the scripts, the debs, the sudoers file, etc):
$ wget http://people.canonical.com/~jamie/cking/aa-corruption.tar.gz
$ tar -zxvf ./aa-corruption.tar.gz
...
$ adb push ./aa-corruption.tar.gz /tmp
$ adb shell
phablet@ubuntu-phablet:~$ cd /tmp
phablet@ubuntu-phablet:~$ tar -zxvf ./aa-corruption.tar.gz
phablet@ubuntu-phablet:~$ sudo mount -o remount,rw /
phablet@ubuntu-phablet:~$ sudo cp ./aa-corruption/etc/sudoers.d/phablet
/etc/sudoers.d/
phablet@ubuntu-phablet:~$ sudo mount -o remount,ro /
phablet@ubuntu-phablet:~$ sudo cp -a ./aa-corruption/home/bug /home
phablet@ubuntu-phablet:~$ exit
$ cd ./aa-corruption
$ ./test-from-host.sh
...
The old script is still in place. Simply adjust ./test-from-host.sh to have:
testscript=/home/bug/test.sh
#testscript=/home/bug/test-with-true.sh"
The kernel team has been able to confirm the symptoms.
References:
* bug 1371771
* bug 1371765
* bug 1377338 |
|
| 2014-10-29 14:57:37 |
Jamie Strandboge |
description |
Symptoms are that cache files in /var/cache/apparmor and profiles in /var/lib/apparmor/profiles are sometimes corrupted after a reboot. We've already fixed several bugs in the apparmor and click-apparmor and made both more robust in the face of corruption, but we've still not found the cause.
The investigation is ongoing and this may not be a problem with the kernel at all, so this bug may be retargeted to another project.
The security team and the kernel team have discussed this a lot and Colin is currently looking at this. This bug is just so it can be tracked. Here is an excerpt from my latest email to Colin:
"I believe I have conclusively ruled out apparmor_parser and aa-clickhook by creating a new 'home/bug/test-with-true.sh'. Here is the test output:
http://paste.ubuntu.com/8648109/
Specifically, home/bug/test-with-true.sh changes the interesting parts of the algorithm to:
1. wait for unity8 to start (this ensures the apparmor upstart job is finished)
2. restore apparmor_parser and aa-clickhook, if needed
3. if /home/bug/profiles... exists, perform a diff -Naur /home/bug/profiles...
/var/lib/apparmor/profiles and fail if differences (note, apparmor_parser
and aa-clickhook were /bin/true during boot so they could not have changed
/var/lib/apparmor/profiles)
4. verify the profiles, exit with error if they do not
5. alternately upgrade/downgrade the packages
6. verify the profiles, exit with error if they do not
7. copy the known good profiles in the previous step to /home/bug/profiles...
8. have apparmor_parser and aa-clickhook point to /bin/true
9. reboot
10. go to step 1
In the paste you'll notice that in step 6 the profiles were successfully created by the installation of the packages, then verified, then copied aside, then apparmor_parser and aa-clickhook diverted, then rebooted, only to have the profiles in /var/lib/apparmor/profiles be different than what was copied aside. It would be nice to verify on your device as well (I reproduced several times here) and verify the reproducer algorithm. I think this suggests this is a kernel issue and not userspace.
IMPORTANT: you will want to update the reproducer and refollow all of these steps (ie, I updated the scripts, the debs, the sudoers file, etc):
$ wget http://people.canonical.com/~jamie/cking/aa-corruption.tar.gz
$ tar -zxvf ./aa-corruption.tar.gz
...
$ adb push ./aa-corruption.tar.gz /tmp
$ adb shell
phablet@ubuntu-phablet:~$ cd /tmp
phablet@ubuntu-phablet:~$ tar -zxvf ./aa-corruption.tar.gz
phablet@ubuntu-phablet:~$ sudo mount -o remount,rw /
phablet@ubuntu-phablet:~$ sudo cp ./aa-corruption/etc/sudoers.d/phablet
/etc/sudoers.d/
phablet@ubuntu-phablet:~$ sudo mount -o remount,ro /
phablet@ubuntu-phablet:~$ sudo cp -a ./aa-corruption/home/bug /home
phablet@ubuntu-phablet:~$ exit
$ cd ./aa-corruption
$ ./test-from-host.sh
...
The old script is still in place. Simply adjust ./test-from-host.sh to have:
testscript=/home/bug/test.sh
#testscript=/home/bug/test-with-true.sh"
The kernel team has been able to confirm the symptoms.
References:
* bug 1371771
* bug 1371765
* bug 1377338 |
Symptoms are that cache files in /var/cache/apparmor and profiles in /var/lib/apparmor/profiles are sometimes corrupted after a reboot. We've already fixed several bugs in the apparmor and click-apparmor and made both more robust in the face of corruption, but we've still not found the cause.
The investigation is ongoing and this may not be a problem with the kernel at all, so this bug may be retargeted to another project.
The security team and the kernel team have discussed this a lot and Colin is currently looking at this. This bug is just so it can be tracked. Here is an excerpt from my latest email to Colin:
"I believe I have conclusively ruled out apparmor_parser and aa-clickhook by creating a new 'home/bug/test-with-true.sh'. Here is the test output:
http://paste.ubuntu.com/8648109/
Specifically, home/bug/test-with-true.sh changes the interesting parts of the algorithm to:
1. wait for unity8 to start (this ensures the apparmor upstart job is finished)
2. restore apparmor_parser and aa-clickhook, if needed
3. if /home/bug/profiles... exists, perform a diff -Naur /home/bug/profiles...
/var/lib/apparmor/profiles and fail if differences (note, apparmor_parser
and aa-clickhook were /bin/true during boot so they could not have changed
/var/lib/apparmor/profiles)
4. verify the profiles, exit with error if they do not
5. alternately upgrade/downgrade the packages
6. verify the profiles, exit with error if they do not
7. copy the known good profiles in the previous step to /home/bug/profiles...
8. have apparmor_parser and aa-clickhook point to /bin/true
9. reboot
10. go to step 1
In the paste you'll notice that in step 6 the profiles were successfully created by the installation of the packages, then verified, then copied aside, then apparmor_parser and aa-clickhook diverted, then rebooted, only to have the profiles in /var/lib/apparmor/profiles be different than what was copied aside. It would be nice to verify on your device as well (I reproduced several times here) and verify the reproducer algorithm. I think this suggests this is a kernel issue and not userspace.
IMPORTANT: you will want to update the reproducer and refollow all of these steps (ie, I updated the scripts, the debs, the sudoers file, etc):
$ wget http://people.canonical.com/~jamie/cking/aa-corruption.tar.gz
$ tar -zxvf ./aa-corruption.tar.gz
...
$ adb push ./aa-corruption.tar.gz /tmp
$ adb shell
phablet@ubuntu-phablet:~$ cd /tmp
phablet@ubuntu-phablet:~$ tar -zxvf ./aa-corruption.tar.gz
phablet@ubuntu-phablet:~$ sudo mount -o remount,rw /
phablet@ubuntu-phablet:~$ sudo cp ./aa-corruption/etc/sudoers.d/phablet
/etc/sudoers.d/
phablet@ubuntu-phablet:~$ sudo mount -o remount,ro /
phablet@ubuntu-phablet:~$ sudo cp -a ./aa-corruption/home/bug /home
phablet@ubuntu-phablet:~$ exit
$ cd ./aa-corruption
$ ./test-from-host.sh
...
The old script is still in place. Simply adjust ./test-from-host.sh to have:
testscript=/home/bug/test.sh
#testscript=/home/bug/test-with-true.sh"
The kernel team has been able to confirm the symptoms.
Related bugs:
* bug 1371771
* bug 1371765
* bug 1377338 |
|
| 2014-10-29 14:59:49 |
Jamie Strandboge |
description |
Symptoms are that cache files in /var/cache/apparmor and profiles in /var/lib/apparmor/profiles are sometimes corrupted after a reboot. We've already fixed several bugs in the apparmor and click-apparmor and made both more robust in the face of corruption, but we've still not found the cause.
The investigation is ongoing and this may not be a problem with the kernel at all, so this bug may be retargeted to another project.
The security team and the kernel team have discussed this a lot and Colin is currently looking at this. This bug is just so it can be tracked. Here is an excerpt from my latest email to Colin:
"I believe I have conclusively ruled out apparmor_parser and aa-clickhook by creating a new 'home/bug/test-with-true.sh'. Here is the test output:
http://paste.ubuntu.com/8648109/
Specifically, home/bug/test-with-true.sh changes the interesting parts of the algorithm to:
1. wait for unity8 to start (this ensures the apparmor upstart job is finished)
2. restore apparmor_parser and aa-clickhook, if needed
3. if /home/bug/profiles... exists, perform a diff -Naur /home/bug/profiles...
/var/lib/apparmor/profiles and fail if differences (note, apparmor_parser
and aa-clickhook were /bin/true during boot so they could not have changed
/var/lib/apparmor/profiles)
4. verify the profiles, exit with error if they do not
5. alternately upgrade/downgrade the packages
6. verify the profiles, exit with error if they do not
7. copy the known good profiles in the previous step to /home/bug/profiles...
8. have apparmor_parser and aa-clickhook point to /bin/true
9. reboot
10. go to step 1
In the paste you'll notice that in step 6 the profiles were successfully created by the installation of the packages, then verified, then copied aside, then apparmor_parser and aa-clickhook diverted, then rebooted, only to have the profiles in /var/lib/apparmor/profiles be different than what was copied aside. It would be nice to verify on your device as well (I reproduced several times here) and verify the reproducer algorithm. I think this suggests this is a kernel issue and not userspace.
IMPORTANT: you will want to update the reproducer and refollow all of these steps (ie, I updated the scripts, the debs, the sudoers file, etc):
$ wget http://people.canonical.com/~jamie/cking/aa-corruption.tar.gz
$ tar -zxvf ./aa-corruption.tar.gz
...
$ adb push ./aa-corruption.tar.gz /tmp
$ adb shell
phablet@ubuntu-phablet:~$ cd /tmp
phablet@ubuntu-phablet:~$ tar -zxvf ./aa-corruption.tar.gz
phablet@ubuntu-phablet:~$ sudo mount -o remount,rw /
phablet@ubuntu-phablet:~$ sudo cp ./aa-corruption/etc/sudoers.d/phablet
/etc/sudoers.d/
phablet@ubuntu-phablet:~$ sudo mount -o remount,ro /
phablet@ubuntu-phablet:~$ sudo cp -a ./aa-corruption/home/bug /home
phablet@ubuntu-phablet:~$ exit
$ cd ./aa-corruption
$ ./test-from-host.sh
...
The old script is still in place. Simply adjust ./test-from-host.sh to have:
testscript=/home/bug/test.sh
#testscript=/home/bug/test-with-true.sh"
The kernel team has been able to confirm the symptoms.
Related bugs:
* bug 1371771
* bug 1371765
* bug 1377338 |
Symptoms are that cache files in /var/cache/apparmor and profiles in /var/lib/apparmor/profiles are sometimes corrupted after a reboot. We've already fixed several bugs in the apparmor and click-apparmor and made both more robust in the face of corruption, but we've still not found the cause. The corruption can still affect real-world devices: if a profile in /var/lib/apparmor/profiles is corrupted and the cache file is out of date, then the profile won't compile and that app/scope won't start.
Workaround: remove the affected profile and then run 'sudo aa-clickhook'. This obviously is not viable on an end-user device.
The investigation is ongoing and this may not be a problem with the kernel at all, so this bug may be retargeted to another project.
The security team and the kernel team have discussed this a lot and Colin is currently looking at this. This bug is just so it can be tracked. Here is an excerpt from my latest email to Colin:
"I believe I have conclusively ruled out apparmor_parser and aa-clickhook by creating a new 'home/bug/test-with-true.sh'. Here is the test output:
http://paste.ubuntu.com/8648109/
Specifically, home/bug/test-with-true.sh changes the interesting parts of the algorithm to:
1. wait for unity8 to start (this ensures the apparmor upstart job is finished)
2. restore apparmor_parser and aa-clickhook, if needed
3. if /home/bug/profiles... exists, perform a diff -Naur /home/bug/profiles...
/var/lib/apparmor/profiles and fail if differences (note, apparmor_parser
and aa-clickhook were /bin/true during boot so they could not have changed
/var/lib/apparmor/profiles)
4. verify the profiles, exit with error if they do not
5. alternately upgrade/downgrade the packages
6. verify the profiles, exit with error if they do not
7. copy the known good profiles in the previous step to /home/bug/profiles...
8. have apparmor_parser and aa-clickhook point to /bin/true
9. reboot
10. go to step 1
In the paste you'll notice that in step 6 the profiles were successfully created by the installation of the packages, then verified, then copied aside, then apparmor_parser and aa-clickhook diverted, then rebooted, only to have the profiles in /var/lib/apparmor/profiles be different than what was copied aside. It would be nice to verify on your device as well (I reproduced several times here) and verify the reproducer algorithm. I think this suggests this is a kernel issue and not userspace.
IMPORTANT: you will want to update the reproducer and refollow all of these steps (ie, I updated the scripts, the debs, the sudoers file, etc):
$ wget http://people.canonical.com/~jamie/cking/aa-corruption.tar.gz
$ tar -zxvf ./aa-corruption.tar.gz
...
$ adb push ./aa-corruption.tar.gz /tmp
$ adb shell
phablet@ubuntu-phablet:~$ cd /tmp
phablet@ubuntu-phablet:~$ tar -zxvf ./aa-corruption.tar.gz
phablet@ubuntu-phablet:~$ sudo mount -o remount,rw /
phablet@ubuntu-phablet:~$ sudo cp ./aa-corruption/etc/sudoers.d/phablet
/etc/sudoers.d/
phablet@ubuntu-phablet:~$ sudo mount -o remount,ro /
phablet@ubuntu-phablet:~$ sudo cp -a ./aa-corruption/home/bug /home
phablet@ubuntu-phablet:~$ exit
$ cd ./aa-corruption
$ ./test-from-host.sh
...
The old script is still in place. Simply adjust ./test-from-host.sh to have:
testscript=/home/bug/test.sh
#testscript=/home/bug/test-with-true.sh"
The kernel team has been able to confirm the symptoms.
Related bugs:
* bug 1371771
* bug 1371765
* bug 1377338 |
|
| 2014-10-29 15:01:22 |
Jamie Strandboge |
description |
Symptoms are that cache files in /var/cache/apparmor and profiles in /var/lib/apparmor/profiles are sometimes corrupted after a reboot. We've already fixed several bugs in the apparmor and click-apparmor and made both more robust in the face of corruption, but we've still not found the cause. The corruption can still affect real-world devices: if a profile in /var/lib/apparmor/profiles is corrupted and the cache file is out of date, then the profile won't compile and that app/scope won't start.
Workaround: remove the affected profile and then run 'sudo aa-clickhook'. This obviously is not viable on an end-user device.
The investigation is ongoing and this may not be a problem with the kernel at all, so this bug may be retargeted to another project.
The security team and the kernel team have discussed this a lot and Colin is currently looking at this. This bug is just so it can be tracked. Here is an excerpt from my latest email to Colin:
"I believe I have conclusively ruled out apparmor_parser and aa-clickhook by creating a new 'home/bug/test-with-true.sh'. Here is the test output:
http://paste.ubuntu.com/8648109/
Specifically, home/bug/test-with-true.sh changes the interesting parts of the algorithm to:
1. wait for unity8 to start (this ensures the apparmor upstart job is finished)
2. restore apparmor_parser and aa-clickhook, if needed
3. if /home/bug/profiles... exists, perform a diff -Naur /home/bug/profiles...
/var/lib/apparmor/profiles and fail if differences (note, apparmor_parser
and aa-clickhook were /bin/true during boot so they could not have changed
/var/lib/apparmor/profiles)
4. verify the profiles, exit with error if they do not
5. alternately upgrade/downgrade the packages
6. verify the profiles, exit with error if they do not
7. copy the known good profiles in the previous step to /home/bug/profiles...
8. have apparmor_parser and aa-clickhook point to /bin/true
9. reboot
10. go to step 1
In the paste you'll notice that in step 6 the profiles were successfully created by the installation of the packages, then verified, then copied aside, then apparmor_parser and aa-clickhook diverted, then rebooted, only to have the profiles in /var/lib/apparmor/profiles be different than what was copied aside. It would be nice to verify on your device as well (I reproduced several times here) and verify the reproducer algorithm. I think this suggests this is a kernel issue and not userspace.
IMPORTANT: you will want to update the reproducer and refollow all of these steps (ie, I updated the scripts, the debs, the sudoers file, etc):
$ wget http://people.canonical.com/~jamie/cking/aa-corruption.tar.gz
$ tar -zxvf ./aa-corruption.tar.gz
...
$ adb push ./aa-corruption.tar.gz /tmp
$ adb shell
phablet@ubuntu-phablet:~$ cd /tmp
phablet@ubuntu-phablet:~$ tar -zxvf ./aa-corruption.tar.gz
phablet@ubuntu-phablet:~$ sudo mount -o remount,rw /
phablet@ubuntu-phablet:~$ sudo cp ./aa-corruption/etc/sudoers.d/phablet
/etc/sudoers.d/
phablet@ubuntu-phablet:~$ sudo mount -o remount,ro /
phablet@ubuntu-phablet:~$ sudo cp -a ./aa-corruption/home/bug /home
phablet@ubuntu-phablet:~$ exit
$ cd ./aa-corruption
$ ./test-from-host.sh
...
The old script is still in place. Simply adjust ./test-from-host.sh to have:
testscript=/home/bug/test.sh
#testscript=/home/bug/test-with-true.sh"
The kernel team has been able to confirm the symptoms.
Related bugs:
* bug 1371771
* bug 1371765
* bug 1377338 |
Symptoms are that cache files in /var/cache/apparmor and profiles in /var/lib/apparmor/profiles are sometimes corrupted after a reboot. We've already fixed several bugs in the apparmor and click-apparmor and made both more robust in the face of corruption and we've reduced the impact when there is a corrupted profile, but we've still not found the cause of the corruption. This corruption can still affect real-world devices: if a profile in /var/lib/apparmor/profiles is corrupted and the cache file is out of date, then the profile won't compile and that app/scope won't start.
Workaround: remove the affected profile and then run 'sudo aa-clickhook'. This obviously is not viable on an end-user device.
The investigation is ongoing and this may not be a problem with the kernel at all, so this bug may be retargeted to another project.
The security team and the kernel team have discussed this a lot and Colin is currently looking at this. This bug is just so it can be tracked. Here is an excerpt from my latest email to Colin:
"I believe I have conclusively ruled out apparmor_parser and aa-clickhook by creating a new 'home/bug/test-with-true.sh'. Here is the test output:
http://paste.ubuntu.com/8648109/
Specifically, home/bug/test-with-true.sh changes the interesting parts of the algorithm to:
1. wait for unity8 to start (this ensures the apparmor upstart job is finished)
2. restore apparmor_parser and aa-clickhook, if needed
3. if /home/bug/profiles... exists, perform a diff -Naur /home/bug/profiles...
/var/lib/apparmor/profiles and fail if differences (note, apparmor_parser
and aa-clickhook were /bin/true during boot so they could not have changed
/var/lib/apparmor/profiles)
4. verify the profiles, exit with error if they do not
5. alternately upgrade/downgrade the packages
6. verify the profiles, exit with error if they do not
7. copy the known good profiles in the previous step to /home/bug/profiles...
8. have apparmor_parser and aa-clickhook point to /bin/true
9. reboot
10. go to step 1
In the paste you'll notice that in step 6 the profiles were successfully created by the installation of the packages, then verified, then copied aside, then apparmor_parser and aa-clickhook diverted, then rebooted, only to have the profiles in /var/lib/apparmor/profiles be different than what was copied aside. It would be nice to verify on your device as well (I reproduced several times here) and verify the reproducer algorithm. I think this suggests this is a kernel issue and not userspace.
IMPORTANT: you will want to update the reproducer and refollow all of these steps (ie, I updated the scripts, the debs, the sudoers file, etc):
$ wget http://people.canonical.com/~jamie/cking/aa-corruption.tar.gz
$ tar -zxvf ./aa-corruption.tar.gz
...
$ adb push ./aa-corruption.tar.gz /tmp
$ adb shell
phablet@ubuntu-phablet:~$ cd /tmp
phablet@ubuntu-phablet:~$ tar -zxvf ./aa-corruption.tar.gz
phablet@ubuntu-phablet:~$ sudo mount -o remount,rw /
phablet@ubuntu-phablet:~$ sudo cp ./aa-corruption/etc/sudoers.d/phablet
/etc/sudoers.d/
phablet@ubuntu-phablet:~$ sudo mount -o remount,ro /
phablet@ubuntu-phablet:~$ sudo cp -a ./aa-corruption/home/bug /home
phablet@ubuntu-phablet:~$ exit
$ cd ./aa-corruption
$ ./test-from-host.sh
...
The old script is still in place. Simply adjust ./test-from-host.sh to have:
testscript=/home/bug/test.sh
#testscript=/home/bug/test-with-true.sh"
The kernel team has been able to confirm the symptoms.
Related bugs:
* bug 1371771
* bug 1371765
* bug 1377338 |
|
| 2014-10-29 15:02:34 |
Jamie Strandboge |
description |
Symptoms are that cache files in /var/cache/apparmor and profiles in /var/lib/apparmor/profiles are sometimes corrupted after a reboot. We've already fixed several bugs in the apparmor and click-apparmor and made both more robust in the face of corruption and we've reduced the impact when there is a corrupted profile, but we've still not found the cause of the corruption. This corruption can still affect real-world devices: if a profile in /var/lib/apparmor/profiles is corrupted and the cache file is out of date, then the profile won't compile and that app/scope won't start.
Workaround: remove the affected profile and then run 'sudo aa-clickhook'. This obviously is not viable on an end-user device.
The investigation is ongoing and this may not be a problem with the kernel at all, so this bug may be retargeted to another project.
The security team and the kernel team have discussed this a lot and Colin is currently looking at this. This bug is just so it can be tracked. Here is an excerpt from my latest email to Colin:
"I believe I have conclusively ruled out apparmor_parser and aa-clickhook by creating a new 'home/bug/test-with-true.sh'. Here is the test output:
http://paste.ubuntu.com/8648109/
Specifically, home/bug/test-with-true.sh changes the interesting parts of the algorithm to:
1. wait for unity8 to start (this ensures the apparmor upstart job is finished)
2. restore apparmor_parser and aa-clickhook, if needed
3. if /home/bug/profiles... exists, perform a diff -Naur /home/bug/profiles...
/var/lib/apparmor/profiles and fail if differences (note, apparmor_parser
and aa-clickhook were /bin/true during boot so they could not have changed
/var/lib/apparmor/profiles)
4. verify the profiles, exit with error if they do not
5. alternately upgrade/downgrade the packages
6. verify the profiles, exit with error if they do not
7. copy the known good profiles in the previous step to /home/bug/profiles...
8. have apparmor_parser and aa-clickhook point to /bin/true
9. reboot
10. go to step 1
In the paste you'll notice that in step 6 the profiles were successfully created by the installation of the packages, then verified, then copied aside, then apparmor_parser and aa-clickhook diverted, then rebooted, only to have the profiles in /var/lib/apparmor/profiles be different than what was copied aside. It would be nice to verify on your device as well (I reproduced several times here) and verify the reproducer algorithm. I think this suggests this is a kernel issue and not userspace.
IMPORTANT: you will want to update the reproducer and refollow all of these steps (ie, I updated the scripts, the debs, the sudoers file, etc):
$ wget http://people.canonical.com/~jamie/cking/aa-corruption.tar.gz
$ tar -zxvf ./aa-corruption.tar.gz
...
$ adb push ./aa-corruption.tar.gz /tmp
$ adb shell
phablet@ubuntu-phablet:~$ cd /tmp
phablet@ubuntu-phablet:~$ tar -zxvf ./aa-corruption.tar.gz
phablet@ubuntu-phablet:~$ sudo mount -o remount,rw /
phablet@ubuntu-phablet:~$ sudo cp ./aa-corruption/etc/sudoers.d/phablet
/etc/sudoers.d/
phablet@ubuntu-phablet:~$ sudo mount -o remount,ro /
phablet@ubuntu-phablet:~$ sudo cp -a ./aa-corruption/home/bug /home
phablet@ubuntu-phablet:~$ exit
$ cd ./aa-corruption
$ ./test-from-host.sh
...
The old script is still in place. Simply adjust ./test-from-host.sh to have:
testscript=/home/bug/test.sh
#testscript=/home/bug/test-with-true.sh"
The kernel team has been able to confirm the symptoms.
Related bugs:
* bug 1371771
* bug 1371765
* bug 1377338 |
Symptoms are that cache files in /var/cache/apparmor and profiles in /var/lib/apparmor/profiles are sometimes corrupted after a reboot. We've already fixed several bugs in the apparmor and click-apparmor and made both more robust in the face of corruption and we've reduced the impact when there is a corrupted profile, but we've still not found the cause of the corruption. This corruption can still affect real-world devices: if a profile in /var/lib/apparmor/profiles is corrupted and the cache file is out of date, then the profile won't compile and that app/scope won't start.
Workaround: remove the affected profile and then run 'sudo aa-clickhook'. This obviously is not viable on an end-user device.
The investigation is ongoing and this may not be a problem with the kernel at all, so this bug may be retargeted to another project.
The security team and the kernel team have discussed this a lot and Colin is currently looking at this. This bug is just so it can be tracked. Here is an excerpt from my latest email to Colin:
"I believe I have conclusively ruled out apparmor_parser and aa-clickhook by creating a new 'home/bug/test-with-true.sh'. Here is the test output:
http://paste.ubuntu.com/8648109/
Specifically, home/bug/test-with-true.sh changes the interesting parts of the algorithm to:
1. wait for unity8 to start (this ensures the apparmor upstart job is finished)
2. restore apparmor_parser and aa-clickhook, if needed
3. if /home/bug/profiles... exists, perform a diff -Naur /home/bug/profiles...
/var/lib/apparmor/profiles and fail if differences (note, apparmor_parser
and aa-clickhook were /bin/true during boot so they could not have changed
/var/lib/apparmor/profiles)
4. verify the profiles, exit with error if they do not
5. alternately upgrade/downgrade the packages
6. verify the profiles, exit with error if they do not
7. copy the known good profiles in the previous step to /home/bug/profiles...
8. have apparmor_parser and aa-clickhook point to /bin/true
9. reboot
10. go to step 1
In the paste you'll notice that in step 6 the profiles were successfully created by the installation of the packages, then verified, then copied aside, then apparmor_parser and aa-clickhook diverted, then rebooted, only to have the profiles in /var/lib/apparmor/profiles be different than what was copied aside. It would be nice to verify on your device as well (I reproduced several times here) and verify the reproducer algorithm. I think this suggests this is a kernel issue and not userspace.
IMPORTANT: you will want to update the reproducer and refollow all of these steps (ie, I updated the scripts, the debs, the sudoers file, etc):
$ wget http://people.canonical.com/~jamie/cking/aa-corruption.tar.gz
$ tar -zxvf ./aa-corruption.tar.gz
...
$ adb push ./aa-corruption.tar.gz /tmp
$ adb shell
phablet@ubuntu-phablet:~$ cd /tmp
phablet@ubuntu-phablet:~$ tar -zxvf ./aa-corruption.tar.gz
phablet@ubuntu-phablet:~$ sudo mount -o remount,rw /
phablet@ubuntu-phablet:~$ sudo cp ./aa-corruption/etc/sudoers.d/phablet
/etc/sudoers.d/
phablet@ubuntu-phablet:~$ sudo mount -o remount,ro /
phablet@ubuntu-phablet:~$ sudo cp -a ./aa-corruption/home/bug /home
phablet@ubuntu-phablet:~$ exit
$ cd ./aa-corruption
$ ./test-from-host.sh
...
The old script is still in place. Simply adjust ./test-from-host.sh to have:
testscript=/home/bug/test.sh
#testscript=/home/bug/test-with-true.sh"
The kernel team has verified the above reproducer and symptoms.
Related bugs:
* bug 1371771
* bug 1371765
* bug 1377338 |
|
| 2014-10-29 15:02:43 |
Jamie Strandboge |
tags |
|
application-confinement |
|
| 2014-10-29 15:04:45 |
Jamie Strandboge |
tags |
application-confinement |
apparmor application-confinement |
|
| 2014-10-29 17:50:22 |
Joseph Salisbury |
tags |
apparmor application-confinement |
apparmor application-confinement kernel-key |
|
| 2014-11-06 13:47:21 |
Jamie Strandboge |
tags |
apparmor application-confinement kernel-key |
apparmor application-confinement kernel-key rtm14 |
|
| 2014-11-06 13:47:29 |
Jamie Strandboge |
affects |
linux (Ubuntu) |
system-image (Ubuntu) |
|
| 2014-11-06 13:51:07 |
Stéphane Graber |
bug task added |
|
initramfs-tools-ubuntu-touch (Ubuntu) |
|
| 2014-11-06 13:51:23 |
Stéphane Graber |
bug task added |
|
android (Ubuntu) |
|
| 2014-11-06 13:53:15 |
Jamie Strandboge |
system-image (Ubuntu): assignee |
Colin Ian King (colin-king) |
|
|
| 2014-11-06 13:53:18 |
Jamie Strandboge |
initramfs-tools-ubuntu-touch (Ubuntu): importance |
Undecided |
Critical |
|
| 2014-11-06 13:53:21 |
Jamie Strandboge |
android (Ubuntu): importance |
Undecided |
Critical |
|
| 2014-11-06 13:53:23 |
Jamie Strandboge |
system-image (Ubuntu): status |
Confirmed |
Triaged |
|
| 2014-11-06 13:53:26 |
Jamie Strandboge |
initramfs-tools-ubuntu-touch (Ubuntu): status |
New |
Triaged |
|
| 2014-11-06 13:53:28 |
Jamie Strandboge |
android (Ubuntu): status |
New |
Triaged |
|
| 2014-11-06 14:59:33 |
Michael Frey |
android (Ubuntu): assignee |
|
Ricardo Salveti (rsalveti) |
|
| 2014-11-06 15:33:10 |
Łukasz Zemczak |
bug |
|
|
added subscriber Landing Team Trackers |
| 2014-11-06 15:35:33 |
Olli Ries |
tags |
apparmor application-confinement kernel-key rtm14 |
apparmor application-confinement kernel-key rtm14 touch-2014-11-06 |
|
| 2014-11-06 15:46:27 |
Barry Warsaw |
bug task deleted |
system-image (Ubuntu) |
|
|
| 2014-11-06 15:51:00 |
Olli Ries |
summary |
file corruption on touch images in rw portions of the filesystem |
[TOPBLOCKER] file corruption on touch images in rw portions of the filesystem |
|
| 2014-11-06 16:14:15 |
Łukasz Zemczak |
tags |
apparmor application-confinement kernel-key rtm14 touch-2014-11-06 |
apparmor application-confinement kernel-key lt-blocker lt-category-visible lt-prio-high rtm14 touch-2014-11-06 |
|
| 2014-11-06 19:55:48 |
Jamie Strandboge |
description |
Symptoms are that cache files in /var/cache/apparmor and profiles in /var/lib/apparmor/profiles are sometimes corrupted after a reboot. We've already fixed several bugs in the apparmor and click-apparmor and made both more robust in the face of corruption and we've reduced the impact when there is a corrupted profile, but we've still not found the cause of the corruption. This corruption can still affect real-world devices: if a profile in /var/lib/apparmor/profiles is corrupted and the cache file is out of date, then the profile won't compile and that app/scope won't start.
Workaround: remove the affected profile and then run 'sudo aa-clickhook'. This obviously is not viable on an end-user device.
The investigation is ongoing and this may not be a problem with the kernel at all, so this bug may be retargeted to another project.
The security team and the kernel team have discussed this a lot and Colin is currently looking at this. This bug is just so it can be tracked. Here is an excerpt from my latest email to Colin:
"I believe I have conclusively ruled out apparmor_parser and aa-clickhook by creating a new 'home/bug/test-with-true.sh'. Here is the test output:
http://paste.ubuntu.com/8648109/
Specifically, home/bug/test-with-true.sh changes the interesting parts of the algorithm to:
1. wait for unity8 to start (this ensures the apparmor upstart job is finished)
2. restore apparmor_parser and aa-clickhook, if needed
3. if /home/bug/profiles... exists, perform a diff -Naur /home/bug/profiles...
/var/lib/apparmor/profiles and fail if differences (note, apparmor_parser
and aa-clickhook were /bin/true during boot so they could not have changed
/var/lib/apparmor/profiles)
4. verify the profiles, exit with error if they do not
5. alternately upgrade/downgrade the packages
6. verify the profiles, exit with error if they do not
7. copy the known good profiles in the previous step to /home/bug/profiles...
8. have apparmor_parser and aa-clickhook point to /bin/true
9. reboot
10. go to step 1
In the paste you'll notice that in step 6 the profiles were successfully created by the installation of the packages, then verified, then copied aside, then apparmor_parser and aa-clickhook diverted, then rebooted, only to have the profiles in /var/lib/apparmor/profiles be different than what was copied aside. It would be nice to verify on your device as well (I reproduced several times here) and verify the reproducer algorithm. I think this suggests this is a kernel issue and not userspace.
IMPORTANT: you will want to update the reproducer and refollow all of these steps (ie, I updated the scripts, the debs, the sudoers file, etc):
$ wget http://people.canonical.com/~jamie/cking/aa-corruption.tar.gz
$ tar -zxvf ./aa-corruption.tar.gz
...
$ adb push ./aa-corruption.tar.gz /tmp
$ adb shell
phablet@ubuntu-phablet:~$ cd /tmp
phablet@ubuntu-phablet:~$ tar -zxvf ./aa-corruption.tar.gz
phablet@ubuntu-phablet:~$ sudo mount -o remount,rw /
phablet@ubuntu-phablet:~$ sudo cp ./aa-corruption/etc/sudoers.d/phablet
/etc/sudoers.d/
phablet@ubuntu-phablet:~$ sudo mount -o remount,ro /
phablet@ubuntu-phablet:~$ sudo cp -a ./aa-corruption/home/bug /home
phablet@ubuntu-phablet:~$ exit
$ cd ./aa-corruption
$ ./test-from-host.sh
...
The old script is still in place. Simply adjust ./test-from-host.sh to have:
testscript=/home/bug/test.sh
#testscript=/home/bug/test-with-true.sh"
The kernel team has verified the above reproducer and symptoms.
Related bugs:
* bug 1371771
* bug 1371765
* bug 1377338 |
Symptoms are that cache files in /var/cache/apparmor and profiles in /var/lib/apparmor/profiles are sometimes corrupted after a reboot. We've already fixed several bugs in the apparmor and click-apparmor and made both more robust in the face of corruption and we've reduced the impact when there is a corrupted profile, but we've still not found the cause of the corruption. This corruption can still affect real-world devices: if a profile in /var/lib/apparmor/profiles is corrupted and the cache file is out of date, then the profile won't compile and that app/scope won't start.
Workaround: remove the affected profile and then run 'sudo aa-clickhook'. This obviously is not viable on an end-user device.
The investigation is ongoing and this may not be a problem with the kernel at all, so this bug may be retargeted to another project.
The security team and the kernel team have discussed this a lot and Colin King is currently looking at this. This bug is just so it can be tracked. Here is an excerpt from my latest email to Colin:
"I believe I have conclusively ruled out apparmor_parser and aa-clickhook by creating a new 'home/bug/test-with-true.sh'. Here is the test output:
http://paste.ubuntu.com/8648109/
Specifically, home/bug/test-with-true.sh changes the interesting parts of the algorithm to:
1. wait for unity8 to start (this ensures the apparmor upstart job is finished)
2. restore apparmor_parser and aa-clickhook, if needed
3. if /home/bug/profiles... exists, perform a diff -Naur /home/bug/profiles...
/var/lib/apparmor/profiles and fail if differences (note, apparmor_parser
and aa-clickhook were /bin/true during boot so they could not have changed
/var/lib/apparmor/profiles)
4. verify the profiles, exit with error if they do not
5. alternately upgrade/downgrade the packages
6. verify the profiles, exit with error if they do not
7. copy the known good profiles in the previous step to /home/bug/profiles...
8. have apparmor_parser and aa-clickhook point to /bin/true
9. reboot
10. go to step 1
In the paste you'll notice that in step 6 the profiles were successfully created by the installation of the packages, then verified, then copied aside, then apparmor_parser and aa-clickhook diverted, then rebooted, only to have the profiles in /var/lib/apparmor/profiles be different than what was copied aside. It would be nice to verify on your device as well (I reproduced several times here) and verify the reproducer algorithm. I think this suggests this is a kernel issue and not userspace.
IMPORTANT: you will want to update the reproducer and refollow all of these steps (ie, I updated the scripts, the debs, the sudoers file, etc):
$ wget http://people.canonical.com/~jamie/cking/aa-corruption.tar.gz
$ tar -zxvf ./aa-corruption.tar.gz
...
$ adb push ./aa-corruption.tar.gz /tmp
$ adb shell
phablet@ubuntu-phablet:~$ cd /tmp
phablet@ubuntu-phablet:~$ tar -zxvf ./aa-corruption.tar.gz
phablet@ubuntu-phablet:~$ sudo mount -o remount,rw /
phablet@ubuntu-phablet:~$ sudo cp ./aa-corruption/etc/sudoers.d/phablet
/etc/sudoers.d/
phablet@ubuntu-phablet:~$ sudo mount -o remount,ro /
phablet@ubuntu-phablet:~$ sudo cp -a ./aa-corruption/home/bug /home
phablet@ubuntu-phablet:~$ exit
$ cd ./aa-corruption
$ ./test-from-host.sh
...
The old script is still in place. Simply adjust ./test-from-host.sh to have:
testscript=/home/bug/test.sh
#testscript=/home/bug/test-with-true.sh"
The kernel team has verified the above reproducer and symptoms.
Related bugs:
* bug 1371771
* bug 1371765
* bug 1377338 |
|
| 2014-11-08 10:10:04 |
Niklas Wenzel |
bug |
|
|
added subscriber Niklas Wenzel |
| 2014-11-11 03:28:53 |
Ricardo Salveti |
android (Ubuntu): status |
Triaged |
In Progress |
|
| 2014-11-11 03:29:01 |
Ricardo Salveti |
initramfs-tools-ubuntu-touch (Ubuntu): status |
Triaged |
In Progress |
|
| 2014-11-11 03:29:05 |
Ricardo Salveti |
initramfs-tools-ubuntu-touch (Ubuntu): assignee |
|
Ricardo Salveti (rsalveti) |
|
| 2014-11-12 01:31:59 |
Ricardo Salveti |
android (Ubuntu): assignee |
Ricardo Salveti (rsalveti) |
Sergio Schvezov (sergiusens) |
|
| 2014-11-12 01:32:08 |
Ricardo Salveti |
bug task added |
|
android (Ubuntu RTM) |
|
| 2014-11-12 01:32:32 |
Ricardo Salveti |
bug task added |
|
initramfs-tools-ubuntu-touch (Ubuntu RTM) |
|
| 2014-11-12 01:32:40 |
Ricardo Salveti |
initramfs-tools-ubuntu-touch (Ubuntu): status |
In Progress |
Fix Released |
|
| 2014-11-13 13:37:31 |
Oliver Grawert |
bug task added |
|
android-tools (Ubuntu) |
|
| 2014-11-13 13:37:50 |
Oliver Grawert |
bug task added |
|
android-tools (Ubuntu RTM) |
|
| 2014-11-13 13:38:02 |
Oliver Grawert |
android-tools (Ubuntu): status |
New |
In Progress |
|
| 2014-11-13 13:38:06 |
Oliver Grawert |
android-tools (Ubuntu RTM): status |
New |
In Progress |
|
| 2014-11-13 13:38:09 |
Oliver Grawert |
android-tools (Ubuntu): importance |
Undecided |
Critical |
|
| 2014-11-13 13:38:13 |
Oliver Grawert |
android-tools (Ubuntu RTM): importance |
Undecided |
Critical |
|
| 2014-11-13 13:38:16 |
Oliver Grawert |
android-tools (Ubuntu): assignee |
|
Oliver Grawert (ogra) |
|
| 2014-11-13 13:38:19 |
Oliver Grawert |
android-tools (Ubuntu RTM): assignee |
|
Oliver Grawert (ogra) |
|
| 2014-11-17 15:22:16 |
Ricardo Salveti |
android (Ubuntu RTM): assignee |
|
Ricardo Salveti (rsalveti) |
|
| 2014-11-17 15:22:21 |
Ricardo Salveti |
android (Ubuntu RTM): status |
New |
In Progress |
|
| 2014-11-17 15:22:23 |
Ricardo Salveti |
android (Ubuntu RTM): importance |
Undecided |
Critical |
|
| 2014-11-17 15:22:27 |
Ricardo Salveti |
initramfs-tools-ubuntu-touch (Ubuntu RTM): status |
New |
In Progress |
|
| 2014-11-17 15:22:31 |
Ricardo Salveti |
initramfs-tools-ubuntu-touch (Ubuntu RTM): importance |
Undecided |
Critical |
|
| 2014-11-17 15:22:34 |
Ricardo Salveti |
initramfs-tools-ubuntu-touch (Ubuntu RTM): assignee |
|
Ricardo Salveti (rsalveti) |
|
| 2014-11-17 17:21:47 |
Launchpad Janitor |
android (Ubuntu): status |
In Progress |
Fix Released |
|
| 2014-11-18 02:04:01 |
Ricardo Salveti |
bug task added |
|
linux-mako (Ubuntu) |
|
| 2014-11-18 02:04:16 |
Ricardo Salveti |
bug task added |
|
linux-mako (Ubuntu RTM) |
|
| 2014-11-18 19:17:49 |
Launchpad Janitor |
branch linked |
|
lp:ubuntu/vivid-proposed/initramfs-tools-ubuntu-touch |
|
| 2014-11-19 17:45:31 |
Ricardo Salveti |
linux-mako (Ubuntu): assignee |
|
Colin Ian King (colin-king) |
|
| 2014-11-19 17:45:42 |
Ricardo Salveti |
linux-mako (Ubuntu RTM): assignee |
|
Colin Ian King (colin-king) |
|
| 2014-11-19 17:45:48 |
Ricardo Salveti |
linux-mako (Ubuntu): status |
New |
Confirmed |
|
| 2014-11-19 17:45:53 |
Ricardo Salveti |
linux-mako (Ubuntu RTM): status |
New |
Confirmed |
|
| 2014-11-19 17:45:57 |
Ricardo Salveti |
linux-mako (Ubuntu): importance |
Undecided |
Critical |
|
| 2014-11-19 17:46:01 |
Ricardo Salveti |
linux-mako (Ubuntu RTM): importance |
Undecided |
Critical |
|
| 2014-11-19 17:46:07 |
Ricardo Salveti |
android (Ubuntu RTM): status |
In Progress |
Fix Committed |
|
| 2014-11-19 17:46:14 |
Ricardo Salveti |
initramfs-tools-ubuntu-touch (Ubuntu RTM): status |
In Progress |
Fix Committed |
|
| 2014-11-19 18:09:32 |
Launchpad Janitor |
android (Ubuntu RTM): status |
Fix Committed |
Fix Released |
|
| 2014-11-19 18:09:35 |
Launchpad Janitor |
initramfs-tools-ubuntu-touch (Ubuntu RTM): status |
Fix Committed |
Fix Released |
|
| 2014-11-21 16:51:03 |
Łukasz Zemczak |
removed subscriber Landing Team Trackers |
|
|
|
| 2014-11-21 16:51:24 |
Łukasz Zemczak |
bug |
|
|
added subscriber Landing Team Trackers |
| 2014-11-21 16:51:37 |
Łukasz Zemczak |
tags |
apparmor application-confinement kernel-key lt-blocker lt-category-visible lt-prio-high rtm14 touch-2014-11-06 |
apparmor application-confinement kernel-key lt-category-visible lt-prio-high rtm14 touch-2014-11-06 |
|
| 2014-11-27 18:19:37 |
Colin Ian King |
linux-mako (Ubuntu): assignee |
Colin Ian King (colin-king) |
Paolo Pisati (p-pisati) |
|
| 2014-11-27 18:19:59 |
Colin Ian King |
linux-mako (Ubuntu RTM): assignee |
Colin Ian King (colin-king) |
Paolo Pisati (p-pisati) |
|
| 2014-12-15 19:05:27 |
David Callé |
bug |
|
|
added subscriber David Callé |
| 2015-01-22 19:21:11 |
John McAleely |
bug task added |
|
canonical-devices-system-image |
|
| 2015-01-23 09:47:51 |
Oliver Grawert |
android-tools (Ubuntu): importance |
Critical |
Low |
|
| 2015-01-23 09:47:59 |
Oliver Grawert |
android-tools (Ubuntu RTM): importance |
Critical |
Low |
|
| 2015-01-23 14:01:08 |
Pat McGowan |
canonical-devices-system-image: status |
New |
Fix Released |
|
| 2015-01-28 05:06:33 |
Lime |
bug |
|
|
added subscriber Lime |
| 2015-03-12 15:25:35 |
Łukasz Zemczak |
removed subscriber Landing Team Trackers |
|
|
|
| 2016-07-12 21:04:59 |
平凡 |
linux-mako (Ubuntu): status |
Confirmed |
Fix Released |
|
| 2022-05-31 14:42:32 |
lui jui ni |
bug |
|
|
added subscriber lui jui ni |
