On Thu, Mar 05, 2015 at 11:04:36AM +0900, Minchan Kim wrote:
> 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?
Why 1000?
The UID_MIN and UID_MAX is nothing strictly defined, it's just option
in /etc/login.defs. I guess it's nothing unusually to have system
where UID_MIN is 500 :-)
Karel
--
Karel Zak <[email protected]>
http://karelzak.blogspot.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/