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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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