lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 5 Mar 2015 11:04:36 +0900 From: Minchan Kim <minchan@...nel.org> To: Sergey Senozhatsky <sergey.senozhatsky.work@...il.com> Cc: Andrew Morton <akpm@...ux-foundation.org>, Sergey Senozhatsky <sergey.senozhatsky@...il.com>, Nitin Gupta <ngupta@...are.org>, linux-kernel@...r.kernel.org, Jerome Marchand <jmarchan@...hat.com> Subject: Re: [PATCH 0/2] make automatic device_id generation possible On Thu, Mar 05, 2015 at 10:47:52AM +0900, Sergey Senozhatsky wrote: > On (03/05/15 10:33), Minchan Kim wrote: > > > hm, I can think of a huge build server with tons of users. /dev/zram$(id -u) > > > created during user login and destroyed during logout. so users use theirs own > > > zram devices with predictable device ids (which also makes it simpler for admin) > > > for compilation/etc., and don't pressure hdds that much. > > > > They upgraded the system and from now on, one of app tries automatic > > id with zram for some reason. What happens if he gets some user id > > before the user login? The system should have fallback in the case of > > failing to create own userid assignment. > > we upgraded our scripts but landed some bugs there? it's up to particular > implementation. in your example, I assume, someone used zram with num_devices >= 1000? > that's impossible. current num_devices limitation is 32. and uid-s start from 1000. I meant it. If we support use-defined id and someone have used your idea so he can make zram per-user as uid. After a while, new application stats automatic id assignment so upcoming users can consume upcoming user id. yeah, automaic id will start from 0 so it's very rare to reach 1000 but who knows? My point is in your usecase, the script would be very fragile so it should have second plan like automatic id. > > these scripts should check if device has been created anyway, it just adds -EEXIST > check. in general "what if user space does something wrong" thing can be beaten by > "what if user space does everything right" argument. when script fails we just go > and fix that script, I guess. Yes, I believe finally the script will go automatic id if it was broken. So, why does we should support user-defined id if they finally should turn around from user-defined to automatic? > > -ss > > > > > Hmm, Coexisting specific and automatic id assign seem to be not a > > godd idea. -- Kind regards, Minchan Kim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists