perms question: /var/lock - any reason NOT to make world-writable?
setting up a school lab for students to do a little microcontroller and
serial port programming (e.g. AVR, PIC, Arduino, EZIO, etc). doing this
always hits two permission issues: write access to /dev/tty* and to
/var/lock. obviously the "right" way to manage this is to put users in
the uucp group (why uucp, btw? i thought that was for usenet...). the
lazy admin in me wants to grant write access to everyone - so what risk
would that create? in this setup, i -do- want every user to have these
Re: perms question: /var/lock - any reason NOT to make world-writable?
On Mon, 26 Mar 2007, in the Usenet newsgroup comp.os.linux.admin, in article
<email@example.com>, ben chang wrote:
>setting up a school lab for students to do a little microcontroller and
>serial port programming (e.g. AVR, PIC, Arduino, EZIO, etc). doing this
>always hits two permission issues: write access to /dev/tty* and to
>/var/lock. obviously the "right" way to manage this is to put users in
>the uucp group[/color]
or use a SGID wrapper that handles the lock files and runs the students
code otherwise - but yeah
>(why uucp, btw? i thought that was for usenet...).[/color]
Unix to Unix CoPy - it's used for transferring "stuff" over the serial
line, which could be Usenet News, mail, or regular files. That's the
reason it owns the "Alternate TTY devices" which are also known as
'call out devices" But nothing prevents you from creating some other
group such as 'serial-wankers' and giving group ownership of the desired
serial port. Depending on your version, your distributor may have
included some "let me help you" security Nazi that resets ownership and
permissions to what it considers safe.
>the lazy admin in me wants to grant write access to everyone - so what
>risk would that create? in this setup, i -do- want every user to have
Well, what is in that directory? And what _could_ a malicious user with
write permissions do? "They have write permissions" and that means
they can delete /var/log/subsys even though it should be owned by root.
I suspect making /var/lock sticky might be a suitable way around that,
but without experimenting - who knows.
Did you ever look to see what is world writable on a "normal" system?
Two directories only - /tmp and /var/tmp. I'll leave it as an exercise
to read the FHS to see why, and to see what the actual normal permissions
of those directories are. Disk space has long since become cheap, and it's
not uncommon to see people setting up ~/tmp/ just to avoid the hassle of
multiple users having access to what gets stuffed into /tmp. Setup isn't
easy, but in these days when "loosing your computer privileges" isn't the
kiss of death to your semester that it was in the 1980s, you no longer have
quite the dis-incentive for playing simple pranks like fork-bombing your
fellow students or sticking a dumb script named 'ls-l' in a common directory
that removes all of the files of the person running it.
By the way, you _do_ realize that this newsgroup is not a sanctioned Big
Eight group, and doesn't get the distribution like 'comp.os.linux.security'