Too many items in list

[LeChatP]

Hello sudo-rs maintainers, I'm the dev from RootAsRole, I wish to report a bug 😉

Describe the bug

I wanted to compare the performance scalability of sudo-rs. I got an error when the policy gets too many items :

Benchmark 11: /usr/bin/sudo-rs /usr/bin/true (nb_tasks = 166, nb_users = 1, nb_roles = 1, nb_commands = 1)
/etc/sudoers:167:2953: too many items in list

The line in question :
#1000 ALL = (ALL) NOPASSWD: R1T1, (ALL) NOPASSWD: R1T2, (ALL) NOPASSWD: R1T3, (ALL) NOPASSWD: R1T4, (ALL) NOPASSWD: R1T5, (ALL) NOPASSWD: R1T6, (ALL) NOPASSWD: R1T7, (ALL) NOPASSWD: R1T8, (ALL) NOPASSWD: R1T9, (ALL) NOPASSWD: R1T10, (ALL) NOPASSWD: R1T11, (ALL) NOPASSWD: R1T12, (ALL) NOPASSWD: R1T13, (ALL) NOPASSWD: R1T14, (ALL) NOPASSWD: R1T15, (ALL) NOPASSWD: R1T16, (ALL) NOPASSWD: R1T17, (ALL) NOPASSWD: R1T18, (ALL) NOPASSWD: R1T19, (ALL) NOPASSWD: R1T20, (ALL) NOPASSWD: R1T21, (ALL) NOPASSWD: R1T22, (ALL) NOPASSWD: R1T23, (ALL) NOPASSWD: R1T24, (ALL) NOPASSWD: R1T25, (ALL) NOPASSWD: R1T26, (ALL) NOPASSWD: R1T27, (ALL) NOPASSWD: R1T28, (ALL) NOPASSWD: R1T29, (ALL) NOPASSWD: R1T30, (ALL) NOPASSWD: R1T31, (ALL) NOPASSWD: R1T32, (ALL) NOPASSWD: R1T33, (ALL) NOPASSWD: R1T34, (ALL) NOPASSWD: R1T35, (ALL) NOPASSWD: R1T36, (ALL) NOPASSWD: R1T37, (ALL) NOPASSWD: R1T38, (ALL) NOPASSWD: R1T39, (ALL) NOPASSWD: R1T40, (ALL) NOPASSWD: R1T41, (ALL) NOPASSWD: R1T42, (ALL) NOPASSWD: R1T43, (ALL) NOPASSWD: R1T44, (ALL) NOPASSWD: R1T45, (ALL) NOPASSWD: R1T46, (ALL) NOPASSWD: R1T47, (ALL) NOPASSWD: R1T48, (ALL) NOPASSWD: R1T49, (ALL) NOPASSWD: R1T50, (ALL) NOPASSWD: R1T51, (ALL) NOPASSWD: R1T52, (ALL) NOPASSWD: R1T53, (ALL) NOPASSWD: R1T54, (ALL) NOPASSWD: R1T55, (ALL) NOPASSWD: R1T56, (ALL) NOPASSWD: R1T57, (ALL) NOPASSWD: R1T58, (ALL) NOPASSWD: R1T59, (ALL) NOPASSWD: R1T60, (ALL) NOPASSWD: R1T61, (ALL) NOPASSWD: R1T62, (ALL) NOPASSWD: R1T63, (ALL) NOPASSWD: R1T64, (ALL) NOPASSWD: R1T65, (ALL) NOPASSWD: R1T66, (ALL) NOPASSWD: R1T67, (ALL) NOPASSWD: R1T68, (ALL) NOPASSWD: R1T69, (ALL) NOPASSWD: R1T70, (ALL) NOPASSWD: R1T71, (ALL) NOPASSWD: R1T72, (ALL) NOPASSWD: R1T73, (ALL) NOPASSWD: R1T74, (ALL) NOPASSWD: R1T75, (ALL) NOPASSWD: R1T76, (ALL) NOPASSWD: R1T77, (ALL) NOPASSWD: R1T78, (ALL) NOPASSWD: R1T79, (ALL) NOPASSWD: R1T80, (ALL) NOPASSWD: R1T81, (ALL) NOPASSWD: R1T82, (ALL) NOPASSWD: R1T83, (ALL) NOPASSWD: R1T84, (ALL) NOPASSWD: R1T85, (ALL) NOPASSWD: R1T86, (ALL) NOPASSWD: R1T87, (ALL) NOPASSWD: R1T88, (ALL) NOPASSWD: R1T89, (ALL) NOPASSWD: R1T90, (ALL) NOPASSWD: R1T91, (ALL) NOPASSWD: R1T92, (ALL) NOPASSWD: R1T93, (ALL) NOPASSWD: R1T94, (ALL) NOPASSWD: R1T95, (ALL) NOPASSWD: R1T96, (ALL) NOPASSWD: R1T97, (ALL) NOPASSWD: R1T98, (ALL) NOPASSWD: R1T99, (ALL) NOPASSWD: R1T100, (ALL) NOPASSWD: R1T101, (ALL) NOPASSWD: R1T102, (ALL) NOPASSWD: R1T103, (ALL) NOPASSWD: R1T104, (ALL) NOPASSWD: R1T105, (ALL) NOPASSWD: R1T106, (ALL) NOPASSWD: R1T107, (ALL) NOPASSWD: R1T108, (ALL) NOPASSWD: R1T109, (ALL) NOPASSWD: R1T110, (ALL) NOPASSWD: R1T111, (ALL) NOPASSWD: R1T112, (ALL) NOPASSWD: R1T113, (ALL) NOPASSWD: R1T114, (ALL) NOPASSWD: R1T115, (ALL) NOPASSWD: R1T116, (ALL) NOPASSWD: R1T117, (ALL) NOPASSWD: R1T118, (ALL) NOPASSWD: R1T119, (ALL) NOPASSWD: R1T120, (ALL) NOPASSWD: R1T121, (ALL) NOPASSWD: R1T122, (ALL) NOPASSWD: R1T123, (ALL) NOPASSWD: R1T124, (ALL) NOPASSWD: R1T125, (ALL) NOPASSWD: R1T126, (ALL) NOPASSWD: R1T127, (ALL) NOPASSWD: R1T128, (ALL) NOPASSWD: R1T129, (ALL) NOPASSWD: R1T130, (ALL) NOPASSWD: R1T131, (ALL) NOPASSWD: R1T132, (ALL) NOPASSWD: R1T133, (ALL) NOPASSWD: R1T134, (ALL) NOPASSWD: R1T135, (ALL) NOPASSWD: R1T136, (ALL) NOPASSWD: R1T137, (ALL) NOPASSWD: R1T138, (ALL) NOPASSWD: R1T139, (ALL) NOPASSWD: R1T140, (ALL) NOPASSWD: R1T141, (ALL) NOPASSWD: R1T142, (ALL) NOPASSWD: R1T143, (ALL) NOPASSWD: R1T144, (ALL) NOPASSWD: R1T145, (ALL) NOPASSWD: R1T146, (ALL) NOPASSWD: R1T147, (ALL) NOPASSWD: R1T148, (ALL) NOPASSWD: R1T149, (ALL) NOPASSWD: R1T150, (ALL) NOPASSWD: R1T151, (ALL) NOPASSWD: R1T152, (ALL) NOPASSWD: R1T153, (ALL) NOPASSWD: R1T154, (ALL) NOPASSWD: R1T155, (ALL) NOPASSWD: R1T156, (ALL) NOPASSWD: R1T157, (ALL) NOPASSWD: R1T158, (ALL) NOPASSWD: R1T159, (ALL) NOPASSWD: R1T160, (ALL) NOPASSWD: R1T161, (ALL) NOPASSWD: R1T162, (ALL) NOPASSWD: R1T163, (ALL) NOPASSWD: R1T164, (ALL) NOPASSWD: R1T165, (ALL) NOPASSWD: R1T166

To Reproduce
I made a repo called Rar-perf to test RootAsRole performance scalability. It generates automatically complex sudo and RootAsRole policy I was able to successfully test the performance with sudo original program but with the sudo-rs binary, the program crashes.

Expected behavior
Working?

Environment (please complete the following information):

• Linux distribution: ArchLinux (installed from repo)
• sudo-rs commit hash: `$ sudo-rs -V -> sudo-rs 0.2.7```

Additional context
Btw, I think that sudo-rs has worse performance than sudo. But it needs confirmation.

[squell]

This is a feature, not a bug.

We made a deliberate choice in the sudoers parser to prevent loops that allocate objects in memory from going on for arbitrary amounts of time (or possible infinitely) and eating up tons of memory. I don't know what exactly can go wrong if a setuid program starts thrashing the memory system but I also didn't see any good reason for letting someone find out. The limit for the amount of items in a sudoers config file is set so ridiculously high that real-world configs cannot be impacted by them (and if a sysadmin does run into this error, they deserve it). Of course we could make them 10 times larger than they currently are, but then you could file a bug report with an input that is 10 times larger 😄.

FWIW, I've done some "benchmarking" on sudo-rs in the past, and I've found sudo-rs to be slightly more efficient with small sudoers configs, ogsudo a bit more with longer ones. But I've only done this in an abortive attempt to make an April fools post out of it, complete with Tom's Hardware style graphs measuring the impacts of different graphic cards and whatnot. In earnest, if you're running sudo/sudo-rs so often as to be impacted by its "performance", you really should consider putting all those commands in a script that runs as root.

There is one dramatic exception though: ogsudo expands all aliases defined in a sudoers file, where sudo-rs uses a different algorithm. This means that in deeply nested aliases lists such as the following, sudo-rs is much quicker than ogsudo:

User_Alias FOO0=nobody
User_Alias FOO1=FOO0,FOO0,FOO0
User_Alias FOO2=FOO1,FOO1,FOO1
User_Alias FOO3=FOO2,FOO2,FOO2
User_Alias FOO4=FOO3,FOO3,FOO3
User_Alias FOO5=FOO4,FOO4,FOO4
User_Alias FOO6=FOO5,FOO5,FOO5
User_Alias FOO7=FOO6,FOO6,FOO6
User_Alias SUDO=FOO7,FOO7,%sudo,FOO7,FOO7

SUDO ALL=(ALL:ALL) ALL

But again, I wouldn't care about this, and I don't think the behaviour of ogsudo is a bug either.

In short, a blanket statement like "sudo-rs has better/worse performance" isn't really true, and it's not really relevant either.

[LeChatP]

I get the logic behind "just put everything in a script," but I don’t agree with it --- especially in real-world infrastructure setups. When you're managing large-scale Ansible playbooks, you might have thousands of individual sudo commands across tasks. That's exactly why performance matters. Wrapping everything in scripts just isn't how modern IaC works.

Also, in practice, a lot of companies are stuck dealing with high-level software --- some proprietary nightmares I won’t name (sarcasm, or not 🙃 ) --- that generate massive, unreadable sudo policies on the fly. So yes, performance under load does matter, even if it seems niche.

Right now, I’m working on improving POLP enforcement with more granular rules. As part of that, I’ve been benchmarking my tool against both sudo and sudo-rs to get a sense of how scalable things really are. I get that most people don’t care about sudo performance --- they just slap on ALL ALL=(ALL) NOPASSWD: ALL and move on --- but my tool needs to show good performance as people (like myself) will start using it with precise access control on it.

It felt like sudo-rs got a bit slower than C sudo as I added more rules, but, maybe my laptop was just choking on a background Netflix stream at the same time 😂. However, the performance is not heavily better than C sudo version (that was my point), I was just surprise of that.

[squell]

No, I've noticed the same performance so it's probably not due to Netflix 😉. I'm sure there are some gains to be had in the policy processing department; e.g. sudo-rs parses the rules from left-to-right whereas ogsudo goes right-to-left and might do some short-circuiting that way (we flipped back and forth on this at some point but have settled on left-to-right for now since it's easier to reason about). Or maybe we're simply allocating more on the heap. And optimizing the binary for size instead of speed is probably not helping either.

But to know for certain requires investing time which of course is a precious commodity. Since sudo-rs is a new tool our main focus since 2023 has been to get the policy module correct and maintainable instead of optimizing it (and for future projects, it's probably better to investigate an alternative to /etc/sudoers based configuration anyway).

If enough people start complaining about the speed of sudo-rs I'm sure this could become a roadmap item. Right now we're simply not touting the usual claim that we are "blazingly fast". 😉