Are the UID and GID per-thread? I assume two different telnet sessions would have different credentials.
I strongly agree that there is a need for credentials in embedded applications, but I don't see that they can be tied to the RTEMS shell. I'm not sure how UID and GID work in a single process POSIX thread environment and the little google searching I did ended up with Linux extensions. Do the credentials apply to file opens or message queue opens? > On Nov 19, 2014, at 02:20 , Sebastian Huber > <sebastian.hu...@embedded-brains.de> wrote: > > The goal is to provide different command sets for different users. For > example a system could give the customer a certain command set and the > service personal a different one which includes also maintenance operations. > > Most of the infrastructure was already present. There were just some > missing links in between. > > On 18/11/14 16:11, Gedare Bloom wrote: >> Could you briefly explain a bit more context about the goals for >> implementing access control? That is, is it for compliance to some >> standard, to address a security need, or something else? >> >> Thanks, >> Gedare >> >> On Tue, Nov 18, 2014 at 9:37 AM, Sebastian Huber >> <sebastian.hu...@embedded-brains.de> wrote: >>> This patch set adds access control to the RTEMS shell. The command >>> visibility >>> and ability to execute are determined by the current user environment and >>> per >>> command mode, UID and GID values. The user environment is set up by the >>> rtems_shell_login_check() handler. Commands to alter the mode, UID and GID >>> of >>> commands are added. >>> >>> _______________________________________________ >>> devel mailing list >>> devel@rtems.org >>> http://lists.rtems.org/mailman/listinfo/devel > > -- > Sebastian Huber, embedded brains GmbH > > Address : Dornierstr. 4, D-82178 Puchheim, Germany > Phone : +49 89 189 47 41-16 > Fax : +49 89 189 47 41-09 > E-Mail : sebastian.hu...@embedded-brains.de > PGP : Public key available on request. > > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. > > _______________________________________________ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel Peter ----------------- Peter Dufault HD Associates, Inc. Software and System Engineering _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel