On 30/3/19 2:22 am, Matthew J Fletcher wrote: > Is there a method of hiding (does not appear in a 'ls -l' directory listing, > or > FTP listing) a file ?,. in addition is there a way of making a file > inaccessible > (cannot cat to screen from console, or ftp by guessing the name) ? > > The application of course would still need access via the C api. >
The way I do this is a combination of users, groups, chroot, cmdchown and cmdchmod. Accounts -------- Create /etc/passwd and /etc/group files. Have a `root` entry and then entries for the other levels of access you wish to provide. You may need to have a default set up in code so you can create these files if they do not exist. This is what I do as /etc is in the IMFS file system which is created on each restart. This in turn may require you hold a copy in the non-volatile media you copy to /etc on restart if you allow user accounts to be created. Only store the encrypted keys. Chroot ------ Add an account home directory to a user's passwd entry that can be used as the chroot base. You can then place files else where in the file system they cannot see or access. Remember to add local copies of files parts of the system may need, for example a chroot home directory of user `joe` could be `/homes/joe`, and a copy of `passwd` as `/homes/joe/etc/passwd` is needed so `ls` can work. You will need a copy as symlinks will not work. Commands -------- Use `cmdchown` and `cmdchmod` to control user access to commands. You can control the access to specific commands and so limit what a user can do. https://docs.rtems.org/branches/master/shell/general_commands.html#cmdchown https://docs.rtems.org/branches/master/shell/general_commands.html#cmdchmod Example ------- Together these constructs give you tight control over the accounts and if you provide support to manage the accounts you can control what can be done. A `root` user can do anything and is typically used by the development team and production. You can then create specific types of accounts and use groups to manage them. Lets have `root` as the engineering/development user with open access. We also want an `oem` group and user a product partner can use to do extra things. This may be controlling feature sets and end user can access. Then there are users, and in this example we will have a single user account called `user` with a simple and easy password `password`. The `user` account is given limited access to the file system and commands. The accounts are managed with these files: (note, the password hashes are junk) [/] # cat /etc/passwd root:$2b$0sdsd8&sdj273hdhs8*(sdks^%kkjd:0:0:::: oem:$2b$0sdhdj7263tgdhanansn$53hdshazjW:100:100:::: user:$2b$asjsj*dhdhe627hhj4kl2ldn27ssp2:500:500:::/nvdisk/user: [/] # cat /etc/group root::0: oem::100:root,oem user::500:root,oem,user I hope these files explain themselves. Start a shell using the standard login handler RTEMS provides: void run_shell(bool have_login, rtems_task_priority priority) { rtems_shell_login_check_t login = NULL; rtems_status_code sc; if (have_login) login = rtems_shell_login_check; sc = rtems_shell_init ("sh", 20 * 1024, priority, "/dev/console", 0, 1, login); if (sc != RTEMS_SUCCESSFUL) fprintf (stderr, "shell: starting shell: %s (%d)", rtems_status_text (sc), sc); } The argument `have_login` can be set to `false` to disable the login. This can be useful in development environments where developers are needing to login all the time. A compile time or physical switch can be used to control this argument. Use the `cmdls` command to see what commands are accessible by which users and then use `cmdchown` and `cmdchmod` to control the access: (the list has been shorten) [/] # cmdls r-x------ 0 0 help r-xr-xr-x 0 0 alias r-x------ 0 0 time r-x------ 0 0 cmdls r-x------ 0 0 cmdchown r-x------ 0 0 cmdchmod r-x------ 0 0 joel r-xr-xr-x 0 0 date r-x------ 0 0 echo r-x------ 0 0 edit r-x------ 0 0 sleep r-x------ 0 0 id r-x------ 0 0 tty r-xr-xr-x 0 0 whoami r-x------ 0 0 logoff r-x------ 0 0 setenv r-x------ 0 0 getenv r-x------ 0 0 unsetenv r-x------ 0 0 cp r-xr-xr-x 0 0 pwd r-xr-xr-x 0 0 ls r-x------ 0 0 chdir r-x------ 0 0 mkdir r-x------ 0 0 rmdir r-x------ 0 0 chroot r-x------ 0 0 chmod r-x------ 0 0 cat r-x------ 0 0 mv r-x------ 0 0 rm r-x------ 0 0 ln r-x------ 0 0 dd r-xr-xr-x 0 0 df r-xr-xr-x 0 0 md5 r-xr-xr-x 0 0 shutdown r-x------ 0 0 cpuuse r-x------ 0 0 top r-x------ 0 0 wkspace r-x------ 0 0 malloc r-x------ 0 0 rtrace r-xr-xr-x 0 0 ifconfig r-xr-xr-x 0 0 route r-xr-x--- 100 100 oem-only-cmd r-xr-xr-x 0 0 user-cmd Here you can see commands only root can run: r-x------ 0 0 chroot r-x------ 0 0 chmod r-x------ 0 0 cat Commands all users can run are: r-xr-xr-x 0 0 date r-xr-xr-x 0 0 shutdown A command only `root` and `oem` can run: r-xr-x--- 100 100 oem-only-cmd I like to add a function to execute a shell command and I use this to run the `cmdchown` and `cmdchmod` commands during start up to set up the command perms. These settings are not persistent across reboots. I have also had a `joel` script on the non-volatile disk to do this and then run just that script. You have a few options to select from here. To further improve the user experience I suggest you create `/etc/issue` and `/etc/issue.net` with something suitable. The file can support a few escape controls that can be useful. I do not think they are documented but you can see them in the code here ... https://git.rtems.org/rtems/tree/cpukit/libmisc/shell/shell.c#n556 Chris _______________________________________________ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
