[Bug 1957024] Re: pam-mkhomedir does not honor private home directories
Here is a demonstration as requested in Discourse. These steps were run on a stock image of Ubuntu Impish taken from https://cloud- images.ubuntu.com/impish/current/. Showing the inconsistent behavior of the default settings if the goal is private home directories. Both adduser and useradd create a home directory that is private but pam_mkhomedir.so does not. # enable pam_mkhomedir.so configuration pam-auth-update --enable mkhomedir # create a user with adduser that creates the home directory adduser --disabled-password --gecos adduser homemadebyadduser # create a user with useradd that creates the home directory useradd --create-home homemadebyuseradd # create a user with useradd that does *not* create the home directory so that pam_mkhomedir.so can create it useradd --no-create-home homemadebymkhomedir # trigger pam_mkhomedir.so to create the home directory su - homemadebymkhomedir -c exit The result is inconsistent permissions on the home directories. root@ubuntu:~# ls -al /home total 24 drwxr-xr-x 6 rootroot4096 Jan 11 03:27 . drwxr-xr-x 19 rootroot4096 Jan 11 03:13 .. drwxr-x--- 2 homemadebyadduser homemadebyadduser 4096 Jan 11 03:20 homemadebyadduser drwxr-xr-x 2 homemadebymkhomedir homemadebymkhomedir 4096 Jan 11 03:27 homemadebymkhomedir drwxr-x--- 2 homemadebyuseradd homemadebyuseradd 4096 Jan 11 03:23 homemadebyuseradd drwxr-x--- 4 ubuntu ubuntu 4096 Jan 11 03:15 ubuntu Configuring pam_mkhomedir.so to be consistent with the other tools. # update pam_mkhomedir.so configuration sed -i -e "s/pam_mkhomedir.so$/pam_mkhomedir.so umask=0027/" /usr/share/pam-configs/mkhomedir # enable mkhomedir again pam-auth-update --enable mkhomedir # create a user with useradd that does *not* create the home directory so that pam_mkhomedir.so can create it useradd --no-create-home homemadebymkhomedirpatch # trigger pam_mkhomedir.so to create the home directory su - homemadebymkhomedirpatch -c exit The result is the permissions are consistent with the other tools. root@ubuntu:~# ls -l /home/ total 20 drwxr-x--- 2 homemadebyadduserhomemadebyadduser4096 Jan 11 03:20 homemadebyadduser drwxr-xr-x 2 homemadebymkhomedir homemadebymkhomedir 4096 Jan 11 03:27 homemadebymkhomedir drwxr-x--- 2 homemadebymkhomedirpatch homemadebymkhomedirpatch 4096 Jan 11 03:36 homemadebymkhomedirpatch drwxr-x--- 2 homemadebyuseraddhomemadebyuseradd4096 Jan 11 03:23 homemadebyuseradd drwxr-x--- 4 ubuntu ubuntu 4096 Jan 11 03:15 ubuntu -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1957024 Title: pam-mkhomedir does not honor private home directories To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pam/+bug/1957024/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1150413] Re: Cannot allocate memory if process owned by user with large number of groups
I created a very simple patch that allocates a larger buffer for the contents of /proc/pid/status, and avoids the infinite loop scenario. The buffer could still conceivably fill up, but ps at least won't crash. A better solution would be to dynamically allocate memory when reading /proc/pid/* , but that looks like a much larger code change. Another potential bug is that the output still seems limited. When running './p -e -o tid,supgid --sort supgid' , not all groups are being shown. It may also be a better solution to rework the original ps_supgid_display.patch to fix these issues. e.g. # ./p -e -o tid,supgid --sort supgid | grep 19853 19853 1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234 1235 1236 1237 1238 1239 1240 1241 1242 1243 1244 1245 1246 1247 1248 1249 1250 1251 1252 # cat /proc/19853/status Name: su State: S (sleeping) Tgid: 19853 Pid:19853 PPid: 30058 TracerPid: 0 Uid:1001100110011001 Gid:1351135113511351 FDSize: 256 Groups: 1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234 1235 1236 1237 1238 1239 1240 1241 1242 1243 1244 1245 1246 1247 1248 1249 1250 1251 1252 1253 1254 1255 1256 1257 1258 1259 1260 1261 1262 1263 1264 1265 1266 1267 1268 1269 1270 1271 1272 1273 1274 1275 1276 1277 1278 1279 1280 1281 1282 1283 1284 1285 1286 1287 1288 1289 1290 1291 1292 1293 1294 1295 1296 1297 1298 1299 1300 1301 1302 1303 1304 1305 1306 1307 1308 1309 1310 1311 1312 1313 1314 1315 1316 1317 1318 1319 1320 1321 1322 1323 1324 1325 1326 1327 1328 1329 1330 1331 1332 1333 1334 1335 1336 1337 1338 1339 1340 1341 1342 1343 1344 1345 1346 1347 1348 1349 1350 1351 1353 1354 1355 1356 1357 1358 1359 1360 1361 1362 1363 1364 1365 1366 1367 1368 1369 1370 1371 1372 1373 1374 1375 1376 1377 1378 1379 1380 1381 1382 1383 1384 1385 1386 1387 ... ** Patch added: gid_buffer_problem.patch https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1150413/+attachment/3568801/+files/gid_buffer_problem.patch -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1150413 Title: Cannot allocate memory if process owned by user with large number of groups To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1150413/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1132789] Re: linux-image-3.2.0-38-generic winbind issue
Looking at the changelog, I strongly suspect this bug was introduced by the patch pid/status: show all supplementary groups. Now that more groups are being returned for a process, ps is unable to handle it. I'll look at filing a bug with procps, as that may be better than reverting this patch. Some links * https://lists.ubuntu.com/archives/kernel-team/2013-January/024446.html * https://launchpad.net/ubuntu/precise/+source/linux/3.2.0-38.60 Some sample output from my box where I've duplicated the problem using local users. root@alowther-d02:~# uname -a Linux alowther-d02 3.2.0-36-generic #57-Ubuntu SMP Tue Jan 8 21:44:52 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux root@alowther-d02:~# su - user1 -c ps PID TTY TIME CMD 2586 pts/000:00:00 su 2587 pts/000:00:00 sh 2589 pts/000:00:00 ps root@alowther-d02:~# su - user1 -c cat /proc/self/status Name: cat State: R (running) Tgid: 2580 Pid:2580 PPid: 2578 TracerPid: 0 Uid:1001100110011001 Gid:1351135113511351 FDSize: 64 Groups: 1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234 1235 1236 1237 ... After a reboot into 3.2.0-38-generic root@alowther-d02:~# uname -a Linux alowther-d02 3.2.0-38-generic #61-Ubuntu SMP Tue Feb 19 12:18:21 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux root@alowther-d02:~# su - user1 -c ps xrealloc: realloc(1073741824) failedCannot allocate memory root@alowther-d02:~# su - user1 -c cat /proc/self/status Name: cat State: R (running) Tgid: 2531 Pid:2531 PPid: 2529 TracerPid: 0 Uid:1001100110011001 Gid:1351135113511351 FDSize: 64 Groups: 1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234 1235 1236 1237 1238 1239 1240 1241 1242 1243 1244 1245 1246 1247 1248 1249 1250 1251 1252 1253 1254 1255 1256 1257 1258 1259 1260 1261 1262 1263 1264 1265 1266 1267 1268 1269 1270 1271 1272 1273 1274 1275 1276 1277 1278 1279 1280 1281 1282 1283 1284 1285 1286 1287 1288 1289 1290 1291 1292 1293 1294 1295 1296 1297 1298 1299 1300 1301 1302 1303 1304 1305 1306 1307 1308 1309 1310 1311 1312 1313 1314 1315 1316 1317 1318 1319 1320 1321 1322 1323 1324 1325 1326 1327 1328 1329 1330 1331 1332 1333 1334 1335 1336 1337 1338 1339 1340 1341 1342 1343 1344 1345 1346 1347 1348 1349 1350 1351 1353 1354 1355 1356 1357 1358 1359 1360 1361 1362 1363 1364 1365 1366 1367 1368 1369 1370 1371 1372 1373 1374 1375 1376 1377 1378 1379 1380 1381 1382 1383 1384 1385 1386 1387 ... -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1132789 Title: linux-image-3.2.0-38-generic winbind issue To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1132789/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1150413] [NEW] Cannot allocate memory if process owned by user with large number of groups
Public bug reported: Both ps and pgrep exit with an error like xrealloc: realloc(1073741824) failedCannot allocate memory if there is a process owned by a user with a large number of groups. I suspect this was introduced with a recent kernel patch which no longer limits the number of groups returned by /proc/pid/status to 32. It affects Ubuntu kernel 3.2.0-38.60 and newer. Links * related kernel bug report - https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1132789 * kernel patch - https://lists.ubuntu.com/archives/kernel-team/2013-January/024446.html * kernel 3.2.0-38.60 changelog - https://launchpad.net/ubuntu/precise/+source/linux/3.2.0-38.60 strace ps output where it fails when it gets to the process owned by a user with a large number of groups open(/proc/11860/status, O_RDONLY)= 6 read(6, Name:\tsu\nState:\tS (sleeping)\nTgid:\t11860\nPid:\t11860\nPPid:\t7912\nTracerPid:\t0\nUid:\t1001\t1001\t1001\t1001\nGid:\t1351\t1351\t1351\t1351\nFDSize:\t256\nGroups:\t1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234 1235 1236 1237 1238 1239 1240 1241 1242 1243 1244 1245 1246 1247 1248 1249 1250 1251 1252 1253 1254 1255 1256 1257 1258 1259 1260 1261 1262 1263 1264 1265 1266 1267 1268 1269 1270 1271 1272 1273 1274 1275 1276 1277 1278 1279 1280 1281 1282 1283 1284 1285 1286 1287 1288 1289 1290 1291 1292 1293 1294 1295 1296 1297 1298 1299 1300 1301 1302 1303 1304 1305 1306 1307 1308 1309 1310 1311 1312 1313 1314 1315 1316 1317 1318 1319 1320 1321 1322 1323 1324 1325 1326 1327 1328 1329 1330 1331 1332 1333 1334 1335 1336 1337 1338 1339 1340 1341 1342 1343 1344 1345 1346 1347 1348 1349 1350 1351 1353 1354 1355 1356 1357 1358 1359 1360 1361 1362 1363 1364 1365 1366 1367 1368 1369 1370 1371 1372 1373 1374 1375 1376 1377 1378 1379 1380 1381 13, 1023) = 1023 close(6)= 0 mmap(NULL, 135168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fbcc1e4c000 mremap(0x7fbcc1e4c000, 135168, 266240, MREMAP_MAYMOVE) = 0x7fbcc1e0b000 mremap(0x7fbcc1e0b000, 266240, 528384, MREMAP_MAYMOVE) = 0x7fbcc28cf000 mremap(0x7fbcc28cf000, 528384, 1052672, MREMAP_MAYMOVE) = 0x7fbcc27ce000 mremap(0x7fbcc27ce000, 1052672, 2101248, MREMAP_MAYMOVE) = 0x7fbcc1c6c000 mremap(0x7fbcc1c6c000, 2101248, 4198400, MREMAP_MAYMOVE) = 0x7fbcc186b000 mremap(0x7fbcc186b000, 4198400, 8392704, MREMAP_MAYMOVE) = 0x7fbcc106a000 mremap(0x7fbcc106a000, 8392704, 16781312, MREMAP_MAYMOVE) = 0x7fbcc0069000 mremap(0x7fbcc0069000, 16781312, 33558528, MREMAP_MAYMOVE) = 0x7fbcbe068000 mremap(0x7fbcbe068000, 33558528, 67112960, MREMAP_MAYMOVE) = 0x7fbcba067000 mremap(0x7fbcba067000, 67112960, 134221824, MREMAP_MAYMOVE) = 0x7fbcb2066000 mremap(0x7fbcb2066000, 134221824, 268439552, MREMAP_MAYMOVE) = 0x7fbca2065000 mremap(0x7fbca2065000, 268439552, 536875008, MREMAP_MAYMOVE) = 0x7fbc82064000 mremap(0x7fbc82064000, 536875008, 1073745920, MREMAP_MAYMOVE) = -1 EFAULT (Bad address) mmap(NULL, 1073745920, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory) brk(0x4133c000) = 0x1333000 mmap(NULL, 1073876992, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory) open(/sys/devices/system/cpu/online, O_RDONLY|O_CLOEXEC) = 6 read(6, 0\n, 8192)= 2 close(6)= 0 mmap(NULL, 134217728, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x7fbbfa042000 munmap(0x7fbbfa042000, 33284096)= 0 munmap(0x7fbc, 33824768)= 0 mprotect(0x7fbbfc00, 135168, PROT_READ|PROT_WRITE) = 0 mmap(NULL, 1073745920, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory) write(2, xrealloc: realloc(1073741824) failed, 36xrealloc: realloc(1073741824) failed) = 36 write(2, Cannot allocate memory\n, 23Cannot allocate memory ) = 23 exit_group(1) = ? Steps I was able to use to reproduce the problem with all local users and groups. The number of groups needed to break ps may be different on other systems. root@alowther-d02:~# for i in $(seq 180); do groupadd group$i ; done root@alowther-d02:~# useradd user1 root@alowther-d02:~# su - user1 -c ps No directory, logging in with HOME=/ PID TTY TIME CMD 5182 pts/0 00:00:00 su 5183 pts/0 00:00:00 sh 5185 pts/0 00:00:00 ps root@alowther-d02:~# for i in $(seq 180); do adduser user1 group$i; done /dev/null root@alowther-d02:~# su - user1 -c ps xrealloc: realloc(1073741824) failedCannot allocate memory System info - I also tried using the version of procps from Raring, but it still failed root@alowther-d02:~# lsb_release -rd Description:Ubuntu 12.04.2 LTS Release:12.04 root@alowther-d02:~# uname -a Linux alowther-d02 3.2.0-38-generic #61-Ubuntu SMP Tue Feb 19 12:18:21 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux root@alowther-d02:~# dpkg -l
[Bug 1132789] Re: linux-image-3.2.0-38-generic winbind issue
I've filed a procps bug at https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1150413 It looks like too many groups in /proc/pid/status, combined with a Debian patch to procps will cause an infinite loop that keeps allocating more and more memory until it fails. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1132789 Title: linux-image-3.2.0-38-generic winbind issue To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1132789/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1150413] Re: Cannot allocate memory if process owned by user with large number of groups
I'm not sure the best way to fix this, but I have located the problem.
I've found this bug to be caused by a Debian patch
ps_supgid_display.patch which was initially from the bug report at
http://bugs.debian.org/506303
When any /proc/pid/status has more than 1024 characters before the end
of the Groups line, an infinite loop is entered because the loop never
finds the \n character it expected. Looking back at the strace, the
read of /proc/11860/status is truncated. A succesful part of the
strace is
stat(/proc/1110, {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
open(/proc/1110/stat, O_RDONLY) = 6
read(6, 1110 (npcd) S 1 1108 1108 0 -1 4202816 509903 56395239 0 129102 205
836 161563 37679 20 0 1 0 3191 243957760 263 18446744073709551615 4194304
4219268 140737259370048 140737259368256 140200938633277 0 0 0 16387
18446744071579436968 0 0 17 0 0 0 1348 0 0\n, 1023) = 253
While the loop runs, it keeps allocating more memory for the array of Group IDs
that it has found associated with the process until it fails because there
isn't enough memory to allocate.
The while loop below from the patch is what runs infinitely. The xrealloc
allocates more memory, doubling the amount it wants each time the loop thinks
the array is filled.
+case_Groups:
+isupgid = 0;
+if (*S != '\n'){ // Is there any supplementary group ?
+ P-supgid = (int *) xmalloc(0x0004 * sizeof(int));
+ int vctsize = 0x0004;
+ while (S[1] != '\n' isupgidINT_MAX){ // There is one blank
before '\n'
+if (isupgid == vctsize){
+ vctsize *= 2;
+ P-supgid = (int *)xrealloc(P-supgid,vctsize * sizeof(int));
+}
+P-supgid[isupgid++] = strtol(S,S,10);
+P-nsupgid++;
+ }
+}
+continue;
** Bug watch added: Debian Bug tracker #506303
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=506303
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1150413
Title:
Cannot allocate memory if process owned by user with large number of
groups
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1150413/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1132789] Re: linux-image-3.2.0-38-generic winbind issue
I've also been experiencing this since updating to linux- image-3.2.0-38-generic as part of applying 12.04.2 updates to my servers. I put similar strace info into a comment at http://askubuntu.com/questions/258180/why-does-running-ps-results-in- cannot-allocate-memory-error . I've found the problem occurs when any user with a large number of groups owns a running process. When ps gets to that process, it dies. I've found I was able to duplicate the issue with local accounts with these steps. The number of groups required may depend on the server. root@alowther-d02:~# for i in $(seq 180); do groupadd group$i ; done root@alowther-d02:~# useradd user1 root@alowther-d02:~# su - user1 -c ps No directory, logging in with HOME=/ PID TTY TIME CMD 5182 pts/000:00:00 su 5183 pts/000:00:00 sh 5185 pts/000:00:00 ps root@alowther-d02:~# for i in $(seq 180); do adduser user1 group$i; done /dev/null root@alowther-d02:~# su - user1 -c ps xrealloc: realloc(1073741824) failedCannot allocate memory -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1132789 Title: linux-image-3.2.0-38-generic winbind issue To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1132789/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
