On Tue, Jun 01, 2004 at 07:52:29PM +1000, Darren Tucker wrote: > Luke Kenneth Casson Leighton wrote: > >but i cannot log in as an ordinary user, and i had to grant > >special permission to the _user_ process (NOT sshd or pam > >before a setuid and exec is carried out) to access > >/dev/pts/0. > > By "user process" do you mean sshd running as the user logging in? If > so, that's probably because of Privilege Separation[1]. Try retesting > with "UsePrivilegeSeparation no" in sshd_config. ah ha! let's see.... YEP! that does it. great! okay, so now in order to avoid one auditing experience or should i say something which requires special permissions to be allowed, i have to switch off something that is there for security reasons, ho hum. > When privsep is on, sshd starts running as the user quite early, leaving > behind another process (the "monitor") running as root, while the > unprivileged sshd does most of the work (network comms, protocol > processing, compression and so on). When the user requests a pty, one > is allocated by the monitor (pty allocation is a privileged operation on > some platforms) and a descriptor is passed to the unprivileged child > (the "slave"), which then forks, makes the pty its controlling tty runs > the shell. This is probably what you're seeing. *glurk*... i actually understood that. okay. the "expected" behaviour shall we say of the SE/linux auditing rules that russell has created is that only the sshd domain (where a domain correlates to a process, in this case the "monitor") has been given permission to do ioctl and read and write to the tty (/dev/pts/NN). and the "user" domain, i.e. after a fork() and set(e?)uid() / gid(), is most definitely NOT granted permission to read/write to ssh-specific ptys because only the sshd domain is allowed that. ... russell, et al, is there some way to reflect the above into SE/Linux auditing rules? l. > >in other words, if i understand this correctly, there is a > >bug somewhere in either sshd or pam where control of the > >tty is given at the wrong point, or is not given at all. > > It's not a bug, it's a Feature. > > [1] http://www.citi.umich.edu/u/provos/ssh/privsep.html :) ta. l. _______________________________________________ Pam-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/pam-list
