hi, on a couple of linux machines that are public workstations (i.e. a number of people have accounts and should be able to use the machines), i changed the permissions of /dev/cdrom to 0644 and /dev/fd0 to 0666 to enable the users to access the cdrom and floppy freely. the same (0666) was done for /dev/ttyS? - the users need access to the serial ports. a little while later, however, we had to discover that the permissions had been arbitrarily reset. /dev/fd0 went 0660 and got owned by the last user, group floppy. /dev/cdrom went 0600 <user>.disk /dev/ttyS0 went 0660 root.uucp ??? why does this happen? i noticed the /dev entries changing permissions and ownership whenever they felt like it. that's not how it's supposed to be. when i set fd0 to 0666 root.floppy, i intend it to stay like that until i change it. what is responsible for this change and how can i prevent it? thanks, martin madduck@madduck.net (greetings from the heart of the sun)
on a couple of linux machines that are public workstations (i.e. a number of people have accounts and should be able to use the machines), i changed the permissions of /dev/cdrom to 0644 and /dev/fd0 to 0666 to enable the users to access the cdrom and floppy freely. the same (0666) was done for /dev/ttyS? - the users need access to the serial ports. a little while later, however, we had to discover that the permissions had been arbitrarily reset. This is done when you run SuSEconfig or maybe at the daily cron jobs at midnight ... You should modify the rights in /etc/permissions.* to keep them.
bye! Markus -- _____________________________ Markus Gaugusch ICQ 11374583 markus@gaugusch.dhs.org 98
nope, the changes happened arbitrarily without cron interaction. martin madduck@madduck.net (greetings from the heart of the sun)
Hi Martin,
hi, on a couple of linux machines that are public workstations (i.e. a number of people have accounts and should be able to use the machines), i changed the permissions of /dev/cdrom to 0644 and /dev/fd0 to 0666 to enable the users to access the cdrom and floppy freely. the same (0666) was done for /dev/ttyS? - the users need access to the serial ports. a little while later, however, we had to discover that the permissions had been arbitrarily reset.
/dev/fd0 went 0660 and got owned by the last user, group floppy. /dev/cdrom went 0600 <user>.disk /dev/ttyS0 went 0660 root.uucp
??? why does this happen? i noticed the /dev entries changing permissions and ownership whenever they felt like it. that's not how it's supposed to be. when i set fd0 to 0666 root.floppy, i intend it to stay like that until i change it. what is responsible for this change and how can i prevent it?
is it possible that the machine you're using is a redhat box or similar? This action looks like it's caused by a PAM module that isn't shipped with SuSE linux (pam_console). We have found that it is useful but it also brings along some problems (also security related) that aren't easy to come by.
thanks, martin
Thanks,
Roman.
--
- -
| Roman Drahtmüller
is it possible that the machine you're using is a redhat box or similar?
<timid>yes</timid> sorry for posting to suse-security then, but you guys are just way more competent than any redhat mailing list i"ve seen so far. and i am about to join the crew and abandon redhat...
This action looks like it's caused by a PAM module that isn't shipped with SuSE linux (pam_console). We have found that it is useful but it also brings along some problems (also security related) that aren't easy to come by.
i will look at this... thanks, martin madduck@madduck.net (greetings from the heart of the sun)
This action looks like it's caused by a PAM module that isn't shipped with SuSE linux (pam_console). We have found that it is useful but it also brings along some problems (also security related) that aren't easy to come by.
so i obviously have /lib/security/pam_console.so and it is mentioned in a couple of files in /etc/pam.d. [nathaniel: check this out - it makes sense...] <snip from man pam_console> When a user logs in at the console and no other user is currently logged in at the console, pam_console.so will change permissions and ownership of files as described in the file /etc/security/console.perms. That user may then log in on other terminals that are considered part of the console, and as long as the user is still logged in at any one of those terminals, that user will own those devices. When the user logs out of the last terminal, the console may be taken by the next user to log in. Other users who have logged in at the console during the time that the first user was logged in will not be given ownership of the devices unless they log in on one of the terminals; having done so on any one terminal, the next user will own those devices until he or she has logged out of every ter minal that is part of the physical console. Then the race can start for the next user. In practice, this is not a problem; the physical console is not generally in use by many people at the same time, and pam_console.so just tries to do the right thing in weird cases. </snip> so this is a good idea and it makes sense, but what it means that i cannot use the cdrom for instance from an ssh console if i wasn't the user last logged in physically? of course, we don't really want this, because then i could freely do whatever i wish with the floppy of someone else. my question then (considering that i will probably go ahead and amend /etc/security/console.perms appropriately) is how suse handles this. so on a suse system, what determines what to do if a ssh user and a console user both request /dev/ttyS0 write access, and how will this situation be handled? martin madduck@madduck.net (greetings from the heart of the sun)
so this is a good idea and it makes sense, but what it means that i cannot use the cdrom for instance from an ssh console if i wasn't the user last logged in physically? of course, we don't really want this, because then i could freely do whatever i wish with the floppy of someone else.
Right.
my question then (considering that i will probably go ahead and amend /etc/security/console.perms appropriately) is how suse handles this. so on a suse system, what determines what to do if a ssh user and a console user both request /dev/ttyS0 write access, and how will this situation be handled?
One of the reasons why we didn't include the pam_console thingy was that
it may be very hard to tell if a user is logged on on the physical console
(eg you have to check $DISPLAY of the process which logs in a user. If it
isn't local, then the user could have come through an X -query X-session.).
Even without that mechanism it's difficult to chmod or chown a floppy
device or even worse, a cdrom device. If the user changes his IDE setup
and reconfigures his /dev/cdrom symlink, we'd end up with a world-open
hard disk device file which equals to root for just about anybody
capable(READ_MANUAL). Also, what do you do if a user has been logged on to
the console but left behind a process with /dev/vcs1 open, mmap()ed or
reading from it?
Currently, SuSE does chown(),chmod() /dev/tty? within /bin/login after
execve() from mingetty. mingetty does chmod,chown back to root.tty(660).
/dev/vcs? are not touched, the code in login.c is present, but #if'ed 0.
Today's applications using pseudo terminals such as xterm and alike use
the devpts mechanism from glibc + kernel. It works by opening /dev/ptmx
and getting back a valid fd for a master terminal device file, whereas the
name of which can also be obtained. It doesn't require any privs, because
the terminal file is owned by the current fsuid of the opening process
already.
/dev/cdrom, /dev/audio, /dev/dsp or /dev/fb and alike aren't touched in a
SuSE system yet. This might be subject to a change soon... Currently,
mounting a cdrom drive is possible for all users. The filesystem will then
be mounted nosuid,nodev and the files will be owned by the user. See
/etc/fstab, look for "user". audio devices are wide open, which I don't
find too irritating.
Roman.
--
- -
| Roman Drahtmüller
participants (3)
-
MaD dUCK -
Markus Gaugusch -
Roman Drahtmueller