On Sun, Mar 03, 2002 at 09:26:11PM +0100, Poul-Henning Kamp wrote:
I presume you'd push the rules in using sysclt or did you have
something more filesystem like in mind?
Nope, just a sysctl.
I guess then you just need a sysctl which lets you read the rules
for a given devfs mount point and
In message [EMAIL PROTECTED], David Malone writes:
On Sun, Mar 03, 2002 at 09:26:11PM +0100, Poul-Henning Kamp wrote:
I presume you'd push the rules in using sysclt or did you have
something more filesystem like in mind?
Nope, just a sysctl.
I guess then you just need a sysctl which lets
I've checked the manpages, the files in /etc, and Googled, and I can't
find the answer. I am begining to worry there isn't one. How does one
change the permissions on dynamically created devices? That is, when
the node comes into existence, it has the permissions I want, and not
necessarily the
In message [EMAIL PROTECTED], Crist J. Clark writes
:
I've checked the manpages, the files in /etc, and Googled, and I can't
find the answer. I am begining to worry there isn't one. How does one
change the permissions on dynamically created devices? That is, when
the node comes into existence, it
On 03-Mar-2002 (16:31:36/GMT) Crist J. Clark wrote:
How does one change the permissions on dynamically created
devices? That is, when the node comes into existence, it has
the permissions I want, and not necessarily the defaults.
You can (must?) use /etc/rc.devfs
[...]
# Setup DEVFS, ie
On Sun, Mar 03, 2002 at 05:42:10PM +0100, Riccardo Torrini wrote:
On 03-Mar-2002 (16:31:36/GMT) Crist J. Clark wrote:
How does one change the permissions on dynamically created
devices? That is, when the node comes into existence, it has
the permissions I want, and not necessarily the
On 03-Mar-2002 (17:02:35/GMT) Crist J. Clark wrote:
I think some people missed the point of the earlier question.
I'm really sorry :( Next time I'll double read the messages.
Riccardo.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the
On Sun, Mar 03, 2002 at 05:36:04PM +0100, Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Crist J. Clark writes
:
I've checked the manpages, the files in /etc, and Googled, and I can't
find the answer. I am begining to worry there isn't one. How does one
change the permissions on
In message [EMAIL PROTECTED], David Malone writes:
On Sun, Mar 03, 2002 at 05:36:04PM +0100, Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Crist J. Clark writes
:
I've checked the manpages, the files in /etc, and Googled, and I can't
find the answer. I am begining to worry there
Do you have any designs for this ruleset stuff? From what you said
at BSDconEurope it will have to be fairly complicated to achieve
the your aim of being better than a static permission for a given
device.
Not really, the basic idea is just a linked list of rules:
In message [EMAIL PROTECTED], David Malone writes:
Not really, the basic idea is just a linked list of rules:
name==/dev/uscanner* - chmod 0644
driver==bpf - chown user
It's not too much work, I just havn't had the time for it yet.
(Junior Kernel Hackers can apply here :-)
OK -
On Sun, Mar 03, 2002 at 09:26:11PM +0100, Poul-Henning Kamp wrote:
OK - I thought you had something much more complex in mind after
your example: plugging the nuclear reactor into the serial port
where you had a a modem plugged in yesterday.
No, that was to show why persistence is a bad
Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], David Malone writes:
On Sun, Mar 03, 2002 at 05:36:04PM +0100, Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Crist J. Clark writes
:
I've checked the manpages, the files in /etc, and Googled, and I can't
find the answer.
I've often thought that owner, group, and mode should be
defaulted in the registration process for the device.
This would let defaults be set in the source code, so in
the worst case, you can rebuild the kernel to get them.
This would also allow low granularity persistance to be
handled in teh
14 matches
Mail list logo
