AVR Downloader/UploaDEr - Patches: patch #4328, Device locking for Linux
You are not allowed to post comments on this tracker with your current authentication level.
patch #4328: Device locking for Linux
Submitter: | None | ||
Submitted: | Thu 18 Aug 2005 03:24:42 PM UTC | ||
Category: | None | Priority: | 5 - Normal |
Status: | Wont Do | Privacy: | Public |
Assigned to: | joerg_wunsch | Originator Email: | -email is unavailable- |
Open/Closed: | Closed |
Fri 01 Sep 2006 11:48:26 AM UTC, comment #1: |
Joerg Wunsch <joerg_wunsch> |
Thu 18 Aug 2005 03:24:42 PM UTC, original submission:
This patch will make avrdude taking care of device locking management under Linux. However one has to figure how to have two #define used in the patch (HAS_LOCKDEV and LOCKDEV_LOCATION) set into the configure script since I have no experience with the configuration tool.
|
Anonymous |
Attached Files
file #9258: patch2 added by None (2KiB - application/octet-stream)
Depends on the following items: None found
Items that depend on this one: None found
CC list is empty
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Follow 4 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2006-09-01 | joerg_wunsch | Status | None | Wont Do | |
Assigned to | None | joerg_wunsch | |||
Open/Closed | Open | Closed | |||
2005-08-18 | None | Attached File | - | Added patch2, #5047 |
Powered by Savane 3.13-4b48.
Corresponding source code
I hesitate to apply that patch, for the following reasons:
. it is (Redhat?) Linux-only, so only covers parts of the environments
we want to support
. it calls an external program (quite some overhead)
. /usr/sbin/lockdev comes with zero documentation, not even the exit
codes are documented
. /usr/sbin/lockdev is setgid lock, and has had security
vulnerabilities in the past
. The entire idea of /usr/sbin/lockdev is IMHO bogus: why introduce a
separate group for the locks, so you could successfully lock a
device which you then are unable to open? Having the lock directory
owned by the same group as the tty devices would be much better (you
need access permissions to the tty anyway). As there is no
documentation for it, I'd also fear it can lead to DoS situations.
If at all, I'd rather support lockdev(3) functions under Linux, or
uu_lock(3) under FreeBSD. (No idea whether Solaris or MacOS X also
have a library interface for that. Hand-crafting a proper UUCP lock
is a dreadful amount of work, so I'd rather avoid it.) However, those
systems that enjoy /usr/sbin/lockdev will fail then unless the caller
itself is member of group lock. Thus, we probably need a
configuration option whether UUCP-style lock support is to be enabled
on systems where the respective library functions are available.