Re: [systemd-devel] Patch for Smack labelling support in udev
On Thu, Sep 12, 2013 at 10:13 PM, Kok, Auke-jan H
auke-jan.h@intel.com wrote:
On Thu, Sep 12, 2013 at 10:23 AM, Kay Sievers k...@vrfy.org wrote:
On Fri, Aug 9, 2013 at 8:56 PM, Kok, Auke-jan H
auke-jan.h@intel.com wrote:
On Wed, Jul 24, 2013 at 3:15 AM, Reshetova, Elena
elena.reshet...@intel.com wrote:
For example, I can set a couple of smack-related xattrs in one go like
XATTR{security.SMACK64}=*, XATTR{security.SMACK64EXEC}=*.
Doesn't make sense from smack point of view (only smack64 is really
meaningful
on device nodes), but proves that functionality works.
right, but we could be setting other non-SMACK xattrs now all in one
go - for example, SELINUX ones (security.selinux).
Yeah, *looks* powerful, but also scary. :)
Udev now supports:
SECLABEL{smack}=name
http://cgit.freedesktop.org/systemd/systemd/commit/?id=c26547d612733371494330e26c7d3604a5dba3d9
Please check if that works for you.
Thanks,
Kay
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Patch for Smack labelling support in udev
-Original Message-
From: Kay Sievers [mailto:k...@vrfy.org]
Sent: Monday, October 07, 2013 5:34 PM
To: Kok, Auke-jan H
Cc: Reshetova, Elena; Schaufler, Casey; systemd-
de...@lists.freedesktop.org; walyong@samsung.com; Ware, Ryan R
Subject: Re: [systemd-devel] Patch for Smack labelling support in udev
On Thu, Sep 12, 2013 at 10:13 PM, Kok, Auke-jan H auke-
jan.h@intel.com wrote:
On Thu, Sep 12, 2013 at 10:23 AM, Kay Sievers k...@vrfy.org wrote:
On Fri, Aug 9, 2013 at 8:56 PM, Kok, Auke-jan H
auke-jan.h@intel.com wrote:
On Wed, Jul 24, 2013 at 3:15 AM, Reshetova, Elena
elena.reshet...@intel.com wrote:
For example, I can set a couple of smack-related xattrs in one go
like XATTR{security.SMACK64}=*,
XATTR{security.SMACK64EXEC}=*.
Doesn't make sense from smack point of view (only smack64 is really
meaningful on device nodes), but proves that functionality works.
right, but we could be setting other non-SMACK xattrs now all in one
go - for example, SELINUX ones (security.selinux).
Yeah, *looks* powerful, but also scary. :)
Udev now supports:
SECLABEL{smack}=name
http://cgit.freedesktop.org/systemd/systemd/commit/?id=c26547d6127333
71494330e26c7d3604a5dba3d9
Please check if that works for you.
It's OK for devices. It won't work for files in general, as Smack
uses multiple attributes in certain cases. It won't work for any
future LSM that uses multiple SECLABELS on a device. Yes, I have
been requested to support multiple Smack labels on a file in
the past. There are security semantics that could make sense.
Thanks,
Kay
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Patch for Smack labelling support in udev
On Tue, Oct 8, 2013 at 2:54 AM, Schaufler, Casey casey.schauf...@intel.com wrote: http://cgit.freedesktop.org/systemd/systemd/commit/?id=c26547d6127333 71494330e26c7d3604a5dba3d9 Please check if that works for you. It's OK for devices. It won't work for files in general, as Smack uses multiple attributes in certain cases. Right, the udev directive applies to kernel device nodes only, it can't be used for any plain file. It won't work for any future LSM that uses multiple SECLABELS on a device. The code supports lists, but there will be explicit code in udev needed for any future LSM anyway, so this sounds fine, I guess. Yes, I have been requested to support multiple Smack labels on a file in the past. There are security semantics that could make sense. Sounds fine. We can catch up whenever needed. For now the udev directive matches the model we do for sockets, where the actual xattr is hidden; that's why we wanted it for udev in a similar fashion: http://cgit.freedesktop.org/systemd/systemd/tree/src/core/socket.c#n799 Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Patch for Smack labelling support in udev
On Fri, Aug 9, 2013 at 8:56 PM, Kok, Auke-jan H
auke-jan.h@intel.com wrote:
On Wed, Jul 24, 2013 at 3:15 AM, Reshetova, Elena elena.reshet...@intel.com
wrote:
For example, I can set a couple of smack-related xattrs in one go like
XATTR{security.SMACK64}=*, XATTR{security.SMACK64EXEC}=*.
Doesn't make sense from smack point of view (only smack64 is really
meaningful
on device nodes), but proves that functionality works.
right, but we could be setting other non-SMACK xattrs now all in one
go - for example, SELINUX ones (security.selinux).
Yeah, *looks* powerful, but also scary. :)
And selinux is not managed by visible strings exposed to tools, it's
all hidden in a library, and the database returns the stuff to apply.
There should never be the need to set any string from selinux with a
tool carrying static strings.
This looks OK to me, can you take another look at it?
I still can't wrap my head around the issue that we can use udev rules
now to *add* things which will never get removed again. If we add a
rule that set one of these attributes, and remove the rule again, the
applied xattr will never be cleared.
It all sounds not right to me, and I don't think we should go ahead
with anything like this before we have sorted out the responsibilities
and ownership of data we attach to device nodes. We do not do that for
anything else, things just don't pile up, they are reset, cleared when
the config goes away and an event is triggered.
We probably need some concept of ownership, based on xattr names or
namespaces, soemthing that makes it clear who's responsible to
reset/clear the attributes when the config changes.
Not sure, maybe we can just reset all xattrs with an add event, and
declare add as a form of reset to a prisitine state.
The other issue is, that as nice as generic support for xattrs sounds,
it might in the end not be what we should offer to random users.
I really can't decide at this moment, I have to think it through.
Thanks,
Kay
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Patch for Smack labelling support in udev
On Thu, Sep 12, 2013 at 10:13 PM, Kok, Auke-jan H auke-jan.h@intel.com wrote: I realize that unsetting/removal is a concern, but I don't think it should preclude merging code that is better at setting/adding :^) Oh, sure it does. We can and should not add generic and possibly unfinished and only partially working functionality because something *needs* a part of it. That's not how things work. We are actually not even at half of the story needed to get that merged. There is stuff missing, as outlines in the previous mail. :) Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Patch for Smack labelling support in udev
On Thu, Sep 12, 2013 at 10:23 AM, Kay Sievers k...@vrfy.org wrote:
On Fri, Aug 9, 2013 at 8:56 PM, Kok, Auke-jan H
auke-jan.h@intel.com wrote:
On Wed, Jul 24, 2013 at 3:15 AM, Reshetova, Elena
elena.reshet...@intel.com wrote:
For example, I can set a couple of smack-related xattrs in one go like
XATTR{security.SMACK64}=*, XATTR{security.SMACK64EXEC}=*.
Doesn't make sense from smack point of view (only smack64 is really
meaningful
on device nodes), but proves that functionality works.
right, but we could be setting other non-SMACK xattrs now all in one
go - for example, SELINUX ones (security.selinux).
Yeah, *looks* powerful, but also scary. :)
And selinux is not managed by visible strings exposed to tools, it's
all hidden in a library, and the database returns the stuff to apply.
There should never be the need to set any string from selinux with a
tool carrying static strings.
This looks OK to me, can you take another look at it?
I still can't wrap my head around the issue that we can use udev rules
now to *add* things which will never get removed again. If we add a
rule that set one of these attributes, and remove the rule again, the
applied xattr will never be cleared.
It all sounds not right to me, and I don't think we should go ahead
with anything like this before we have sorted out the responsibilities
and ownership of data we attach to device nodes. We do not do that for
anything else, things just don't pile up, they are reset, cleared when
the config goes away and an event is triggered.
We probably need some concept of ownership, based on xattr names or
namespaces, soemthing that makes it clear who's responsible to
reset/clear the attributes when the config changes.
Not sure, maybe we can just reset all xattrs with an add event, and
declare add as a form of reset to a prisitine state.
The other issue is, that as nice as generic support for xattrs sounds,
it might in the end not be what we should offer to random users.
I really can't decide at this moment, I have to think it through.
well, for Tizen at least, we need this functionality. Too many nodes
appear in /dev/ that should only be accessible by certain services
alone, and this is exactly what SMACK adds.
A good example is that SMACK allows us to grant only camera
(/dev/video/*) privileges to approved camera applications, instead of
having every application for a user in a session have full access to
the camera. We get the best of both access control methods.
I realize that unsetting/removal is a concern, but I don't think it
should preclude merging code that is better at setting/adding :^)
The only alternative I see is to create another udev event listener
and have that process set smack labels. That would just duplicate a
lot of udev code... And it still doesn't solve the removal of rules -
that would be something only a e.g. %post script could consistently
do.
Auke
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Patch for Smack labelling support in udev
On Wed, Jul 24, 2013 at 3:15 AM, Reshetova, Elena
elena.reshet...@intel.com wrote:
-Original Message-
From: Kay Sievers [mailto:k...@vrfy.org]
Sent: Tuesday, July 16, 2013 10:12 PM
To: Reshetova, Elena
Cc: Lennart Poettering; systemd-devel@lists.freedesktop.org; Ware, Ryan R;
Schaufler, Casey; walyong@samsung.com
Subject: Re: [systemd-devel] Patch for Smack labelling support in udev
On Tue, Jul 9, 2013 at 4:34 PM, Reshetova, Elena elena.reshet...@intel.com
wrote:
-static int node_permissions_apply(struct udev_device *dev, bool
apply, mode_t mode, uid_t uid, gid_t gid)
+static int node_permissions_apply(struct udev_device *dev, bool
+apply,
mode_t mode,
+ uid_t uid, gid_t gid, struct
+udev_list xattr_list)
Guess we better pass the udev_list as a const pointer here.
Ups, sorry, missed this one, of course it won't even work this way (I
haven't tried to run it yet ...
It looks like it could work, but please test it and make sure it does the
right thing before we go ahead from here.
OK, so now I have tested it and with one minor fix (passing a list entry and
not the whole list in udev-node) it works just fine.
I am able to setup one or more xattrs on device node using the syntax
XATTR{attr_name}=value
For example, I can set a couple of smack-related xattrs in one go like
XATTR{security.SMACK64}=*, XATTR{security.SMACK64EXEC}=*.
Doesn't make sense from smack point of view (only smack64 is really meaningful
on device nodes), but proves that functionality works.
right, but we could be setting other non-SMACK xattrs now all in one
go - for example, SELINUX ones (security.selinux).
I am attaching the patch.
Kay,
This looks OK to me, can you take another look at it?
Auke
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Patch for Smack labelling support in udev
-Original Message-
From: Kay Sievers [mailto:k...@vrfy.org]
Sent: Tuesday, July 16, 2013 10:12 PM
To: Reshetova, Elena
Cc: Lennart Poettering; systemd-devel@lists.freedesktop.org; Ware, Ryan R;
Schaufler, Casey; walyong@samsung.com
Subject: Re: [systemd-devel] Patch for Smack labelling support in udev
On Tue, Jul 9, 2013 at 4:34 PM, Reshetova, Elena elena.reshet...@intel.com
wrote:
-static int node_permissions_apply(struct udev_device *dev, bool
apply, mode_t mode, uid_t uid, gid_t gid)
+static int node_permissions_apply(struct udev_device *dev, bool
+apply,
mode_t mode,
+ uid_t uid, gid_t gid, struct
+udev_list xattr_list)
Guess we better pass the udev_list as a const pointer here.
Ups, sorry, missed this one, of course it won't even work this way (I
haven't tried to run it yet ...
It looks like it could work, but please test it and make sure it does the
right thing before we go ahead from here.
OK, so now I have tested it and with one minor fix (passing a list entry and
not the whole list in udev-node) it works just fine.
I am able to setup one or more xattrs on device node using the syntax
XATTR{attr_name}=value
For example, I can set a couple of smack-related xattrs in one go like
XATTR{security.SMACK64}=*, XATTR{security.SMACK64EXEC}=*.
Doesn't make sense from smack point of view (only smack64 is really meaningful
on device nodes), but proves that functionality works.
I am attaching the patch.
Best Regards,
Elena.
0001-Adding-extended-attribute-support-for-udev-nodes-lab.patch
Description: Binary data
smime.p7s
Description: S/MIME cryptographic signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Patch for Smack labelling support in udev
-Original Message- From: Kay Sievers [mailto:k...@vrfy.org] Sent: Tuesday, July 16, 2013 10:12 PM To: Reshetova, Elena Cc: Lennart Poettering; systemd-devel@lists.freedesktop.org; Ware, Ryan R; Schaufler, Casey; walyong@samsung.com Subject: Re: [systemd-devel] Patch for Smack labelling support in udev On Tue, Jul 9, 2013 at 4:34 PM, Reshetova, Elena elena.reshet...@intel.com wrote: -static int node_permissions_apply(struct udev_device *dev, bool apply, mode_t mode, uid_t uid, gid_t gid) +static int node_permissions_apply(struct udev_device *dev, bool +apply, mode_t mode, + uid_t uid, gid_t gid, struct +udev_list xattr_list) Guess we better pass the udev_list as a const pointer here. Ups, sorry, missed this one, of course it won't even work this way (I haven't tried to run it yet ... It looks like it could work, but please test it and make sure it does the right thing before we go ahead from here. Sure, I will let you know when I am done with testing: unfortunately I have to focus on some urgent issues first now, but I will get back to it asap (hopefully by the end of this week). Best Regards, Elena. smime.p7s Description: S/MIME cryptographic signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Patch for Smack labelling support in udev
On Tue, Jul 9, 2013 at 4:34 PM, Reshetova, Elena elena.reshet...@intel.com wrote: -static int node_permissions_apply(struct udev_device *dev, bool apply, mode_t mode, uid_t uid, gid_t gid) +static int node_permissions_apply(struct udev_device *dev, bool apply, mode_t mode, + uid_t uid, gid_t gid, struct +udev_list xattr_list) Guess we better pass the udev_list as a const pointer here. Ups, sorry, missed this one, of course it won't even work this way (I haven't tried to run it yet ... It looks like it could work, but please test it and make sure it does the right thing before we go ahead from here. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Patch for Smack labelling support in udev
Hi,
Does the attached patch look better? I have fixed the sequence of xattr
processing (now just after uid, gid, mode and etc.) + switched to use a list
for collecting the xattrs.
I think it is more generic to allow many xattrs to be set for one node, since
it is normal use case.
Best Regards,
Elena
-Original Message-
From: Kay Sievers [mailto:k...@vrfy.org]
Sent: Wednesday, July 03, 2013 2:23 PM
To: Reshetova, Elena
Cc: Lennart Poettering; systemd-devel@lists.freedesktop.org; Ware, Ryan R;
Schaufler, Casey; walyong@samsung.com
Subject: Re: [systemd-devel] Patch for Smack labelling support in udev
On Wed, Jul 3, 2013 at 1:04 PM, Reshetova, Elena elena.reshet...@intel.com
wrote:
Things like:
..., XATTR{foo}=foo, XATTR{bar}=bar
would just eat the entire foo key. That is intentional? We usually
have lists for that, or we would not allow 2 keys ...
Hm.. Do we want to allow multiple xattr setup on the same node?
I don't know. But we need to sure what we want and document it that way. :)
I guess this
can make sense if for example one is to setup the security label and
another one some other attribute.
So, I guess then it has to be stored in a list. I will take a look on
how it is done for other cases.
Could you please point to the right example on how such case is
handled in udev (maybe from other permissions or attributes)? Some
particular case that I should take as an example?
udev_list_entry_add(event-run_list, ...
and quite a few other examples.
If pairs of values that belong to each other are allocated, we better
check if we run into allocation problems. Udev ignores that in some
places and goes ahead as the value would not have been set at all. But
with pairs, we should not end up with inconsistent pairs which have only the
name or the value set.
The:
if ((xattr_name) (xattr_label))
should then just become:
if (xattr_name)
OK, and then I guess I would need to check during parcing that they
are both set correctly and unset the other one, if one is missing, right?
Yeah, it's pretty simple: just always leave a clean state, or give up where
the error happens. Do leave invalid/partial data around and try to cope with
it later.
Kay
0001-Adding-extended-attribute-support-for-udev-nodes-lab.patch
Description: Binary data
smime.p7s
Description: S/MIME cryptographic signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Patch for Smack labelling support in udev
On Tue, Jul 9, 2013 at 3:47 PM, Reshetova, Elena
elena.reshet...@intel.com wrote:
Does the attached patch look better? I have fixed the sequence of xattr
processing (now just after uid, gid, mode and etc.) + switched to use a list
for collecting the xattrs.
I think it is more generic to allow many xattrs to be set for one node, since
it is normal use case.
@@ -252,11 +256,13 @@ void udev_node_update_old_links(struct udev_device
*dev, struct udev_device *dev
}
}
-static int node_permissions_apply(struct udev_device *dev, bool apply,
mode_t mode, uid_t uid, gid_t gid)
+static int node_permissions_apply(struct udev_device *dev, bool apply,
mode_t mode,
+ uid_t uid, gid_t gid, struct udev_list
xattr_list)
Guess we better pass the udev_list as a const pointer here.
@@ -288,13 +294,28 @@ static int node_permissions_apply(struct udev_device
*dev, bool apply, mode_t mo
label_fix(devnode, true, false);
}
+udev_list_entry_foreach(xattr_entry, xattr_list) {
Does that really work with the non-pointer, seems a bit odd that way?
@@ -2307,6 +2323,24 @@ int udev_rules_apply_to_event(struct udev_rules
*rules, struct udev_event *event
rules_str(rules, rule-rule.filename_off),
rule-rule.filename_line);
break;
+ case TK_A_XATTR: {
+struct udev_list_entry *xattr_entry;
This seems unused.
Kay
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Patch for Smack labelling support in udev
-static int node_permissions_apply(struct udev_device *dev, bool
apply, mode_t mode, uid_t uid, gid_t gid)
+static int node_permissions_apply(struct udev_device *dev, bool apply,
mode_t mode,
+ uid_t uid, gid_t gid, struct
+udev_list xattr_list)
Guess we better pass the udev_list as a const pointer here.
Ups, sorry, missed this one, of course it won't even work this way (I haven't
tried to run it yet - I am setting the environment right now since I don't
have systemd-powered machine as a host).
Here is the fixed patch with the unused part removed also.
Best Regards,
Elena.
-Original Message-
From: Kay Sievers [mailto:k...@vrfy.org]
Sent: Tuesday, July 09, 2013 5:03 PM
To: Reshetova, Elena
Cc: Lennart Poettering; systemd-devel@lists.freedesktop.org; Ware, Ryan R;
Schaufler, Casey; walyong@samsung.com
Subject: Re: [systemd-devel] Patch for Smack labelling support in udev
On Tue, Jul 9, 2013 at 3:47 PM, Reshetova, Elena elena.reshet...@intel.com
wrote:
Does the attached patch look better? I have fixed the sequence of
xattr processing (now just after uid, gid, mode and etc.) + switched
to use a list for collecting the xattrs.
I think it is more generic to allow many xattrs to be set for one
node, since it is normal use case.
@@ -252,11 +256,13 @@ void udev_node_update_old_links(struct udev_device
*dev, struct udev_device *dev
}
}
-static int node_permissions_apply(struct udev_device *dev, bool
apply, mode_t mode, uid_t uid, gid_t gid)
+static int node_permissions_apply(struct udev_device *dev, bool apply,
mode_t mode,
+ uid_t uid, gid_t gid, struct
+udev_list xattr_list)
Guess we better pass the udev_list as a const pointer here.
@@ -288,13 +294,28 @@ static int node_permissions_apply(struct udev_device
*dev, bool apply, mode_t mo
label_fix(devnode, true, false);
}
+udev_list_entry_foreach(xattr_entry, xattr_list) {
Does that really work with the non-pointer, seems a bit odd that way?
@@ -2307,6 +2323,24 @@ int udev_rules_apply_to_event(struct udev_rules
*rules, struct udev_event *event
rules_str(rules,
rule-rule.filename_off),
rule-rule.filename_line);
break;
+ case TK_A_XATTR: {
+struct udev_list_entry *xattr_entry;
This seems unused.
Kay
0001-Adding-extended-attribute-support-for-udev-nodes-lab.patch
Description: Binary data
smime.p7s
Description: S/MIME cryptographic signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Patch for Smack labelling support in udev
-Original Message-
From: Kay Sievers [mailto:k...@vrfy.org]
Sent: Tuesday, June 25, 2013 7:30 PM
To: Reshetova, Elena
Cc: Lennart Poettering; systemd-devel@lists.freedesktop.org; Ware, Ryan R;
Schaufler, Casey; walyong@samsung.com
Subject: Re: [systemd-devel] Patch for Smack labelling support in udev
On Tue, Jun 25, 2013 at 5:23 PM, Reshetova, Elena elena.reshet...@intel.com
wrote:
Here is the draft for the changed patch. Is it along the lines you
were thinking about?
Please ignore the small details such as cosmetics and etc. now: I am
still planning to test it properly and cleanup, but first I want to
understand if I am moving towards the right way.
Things like:
..., XATTR{foo}=foo, XATTR{bar}=bar
would just eat the entire foo key. That is intentional? We usually have lists
for that, or we would not allow 2 keys ...
Hm.. Do we want to allow multiple xattr setup on the same node? I guess this
can make sense if for example one is to setup the security label and another
one some other attribute.
So, I guess then it has to be stored in a list. I will take a look on how it
is done for other cases.
Could you please point to the right example on how such case is handled in
udev (maybe from other permissions or attributes)? Some particular case that I
should take as an example?
The tokens in the enum are the sort order of execution, the order has
meaning, it's not just a list. The XATTR key belongs more to the other
permissions keys than to the end of the list.
Oh, ok, didn't know this (as many other things about udev :)). I will fix this
part.
If pairs of values that belong to each other are allocated, we better check
if we run into allocation problems. Udev ignores that in some places and goes
ahead as the value would not have been set at all. But with pairs, we should
not end up with inconsistent pairs which have only the name or the value set.
The:
if ((xattr_name) (xattr_label))
should then just become:
if (xattr_name)
.
OK, and then I guess I would need to check during parcing that they are both
set correctly and unset the other one, if one is missing, right?
Best Regards,
Elena.
smime.p7s
Description: S/MIME cryptographic signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Patch for Smack labelling support in udev
On Wed, Jul 3, 2013 at 1:04 PM, Reshetova, Elena
elena.reshet...@intel.com wrote:
Things like:
..., XATTR{foo}=foo, XATTR{bar}=bar
would just eat the entire foo key. That is intentional? We usually have lists
for that, or we would not allow 2 keys ...
Hm.. Do we want to allow multiple xattr setup on the same node?
I don't know. But we need to sure what we want and document it that way. :)
I guess this
can make sense if for example one is to setup the security label and another
one some other attribute.
So, I guess then it has to be stored in a list. I will take a look on how it
is done for other cases.
Could you please point to the right example on how such case is handled in
udev (maybe from other permissions or attributes)? Some particular case that I
should take as an example?
udev_list_entry_add(event-run_list, ...
and quite a few other examples.
If pairs of values that belong to each other are allocated, we better check
if we run into allocation problems. Udev ignores that in some places and goes
ahead as the value would not have been set at all. But with pairs, we should
not end up with inconsistent pairs which have only the name or the value set.
The:
if ((xattr_name) (xattr_label))
should then just become:
if (xattr_name)
OK, and then I guess I would need to check during parcing that they are both
set correctly and unset the other one, if one is missing, right?
Yeah, it's pretty simple: just always leave a clean state, or give up
where the error happens. Do leave invalid/partial data around and try
to cope with it later.
Kay
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Patch for Smack labelling support in udev
Hi,
Here is the draft for the changed patch. Is it along the lines you were
thinking about?
Please ignore the small details such as cosmetics and etc. now: I am still
planning to test it properly and cleanup, but first I want to understand if
I am moving towards the right way.
Best Regards,
Elena.
-Original Message-
From: Lennart Poettering [mailto:lenn...@poettering.net]
Sent: Thursday, June 20, 2013 10:08 PM
To: Reshetova, Elena
Cc: Kok, Auke-jan H; Kyungmin Park; Schaufler, Casey;
systemd-devel@lists.freedesktop.org; walyong@samsung.com; Ware, Ryan R
Subject: Re: [systemd-devel] Patch for Smack labelling support in udev
On Wed, 19.06.13 12:09, Reshetova, Elena (elena.reshet...@intel.com) wrote:
This is the patch for review for enabling smack labelling for
device
nodes.
The functionality and reasoning is inside. I will be happy to
answer any questions.
So, this needs some HAVE_SMACK ifdeffery at least.
That said, I wonder if we should instead make this a generic
XATTR{foobar}=waldo thing. Kay?
Any update for this? if we use SMACK for udev, it requires it.
Lennart's suggestion seems more than reasonable - it would make it
generic
enough to do:
XATTR{security.SMACK64}=label
which I think is all we need here. Elena, do you need help respinning
this?
Sorry for the silence, it seems like I totally missed these replies
(got buried in my mailbox)!
Sure, I can make a change, but I am not exactly sure what you mean by
this:
XATTR{security.SMACK64}=label. Adding simple HAVE_SMACK ifdeffery
is easy, but the later part I didn't really understand.
Well, we just want this to be a bit more generic. i.e. we want a generic
XATTR{} concept for udev rules, so that you can set any kind of xattrs, not
just the ones SMACK needs. That way we can nicely handle the SMACK case, but
possibly also handle a lot of other cases where people just want to use
xattrs. Also the SMACK-specific ifdeffery then just becomes an
XATTR-specific ifdeffery...
If it is just longer to explain it to me, Auke, you can go ahead and
make a change and I will just learn from looking into it :)
Unfortunately, I don't know systemd code well enough.
Well, you did the initial patch, right? Changing this to be this tiny bit
mor expressive should be easy. But anyway, I'll let you an Auke figure this
out...
Lennart
--
Lennart Poettering - Red Hat, Inc.
0001-Adding-extended-attribute-support-for-udev-nodes-lab.patch
Description: Binary data
smime.p7s
Description: S/MIME cryptographic signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Patch for Smack labelling support in udev
On Tue, Jun 25, 2013 at 5:23 PM, Reshetova, Elena
elena.reshet...@intel.com wrote:
Here is the draft for the changed patch. Is it along the lines you were
thinking about?
Please ignore the small details such as cosmetics and etc. now: I am still
planning to test it properly and cleanup, but first I want to understand if
I am moving towards the right way.
Things like:
..., XATTR{foo}=foo, XATTR{bar}=bar
would just eat the entire foo key. That is intentional? We usually
have lists for that, or we would not allow 2 keys ...
The tokens in the enum are the sort order of execution, the order has
meaning, it's not just a list. The XATTR key belongs more to the other
permissions keys than to the end of the list.
If pairs of values that belong to each other are allocated, we better
check if we run into allocation problems. Udev ignores that in some
places and goes ahead as the value would not have been set at all. But
with pairs, we should not end up with inconsistent pairs which have
only the name or the value set.
The:
if ((xattr_name) (xattr_label))
should then just become:
if (xattr_name)
.
Thanks,
Kay
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Patch for Smack labelling support in udev
On Wed, 19.06.13 12:09, Reshetova, Elena (elena.reshet...@intel.com) wrote:
This is the patch for review for enabling smack labelling for device
nodes.
The functionality and reasoning is inside. I will be happy to answer
any questions.
So, this needs some HAVE_SMACK ifdeffery at least.
That said, I wonder if we should instead make this a generic
XATTR{foobar}=waldo thing. Kay?
Any update for this? if we use SMACK for udev, it requires it.
Lennart's suggestion seems more than reasonable - it would make it generic
enough to do:
XATTR{security.SMACK64}=label
which I think is all we need here. Elena, do you need help respinning this?
Sorry for the silence, it seems like I totally missed these replies (got
buried in my mailbox)!
Sure, I can make a change, but I am not exactly sure what you mean by this:
XATTR{security.SMACK64}=label. Adding simple HAVE_SMACK ifdeffery is
easy, but the later part I didn't really understand.
Well, we just want this to be a bit more generic. i.e. we want a generic
XATTR{} concept for udev rules, so that you can set any kind of xattrs,
not just the ones SMACK needs. That way we can nicely handle the SMACK
case, but possibly also handle a lot of other cases where people just
want to use xattrs. Also the SMACK-specific ifdeffery then just becomes
an XATTR-specific ifdeffery...
If it is just longer to explain it to me, Auke, you can go ahead and make a
change and I will just learn from looking into it :) Unfortunately, I don't
know systemd code well enough.
Well, you did the initial patch, right? Changing this to be this tiny
bit mor expressive should be easy. But anyway, I'll let you an Auke
figure this out...
Lennart
--
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Patch for Smack labelling support in udev
-Original Message-
From: Lennart Poettering [mailto:lenn...@poettering.net]
Sent: Thursday, June 20, 2013 10:08 PM
To: Reshetova, Elena
On Wed, 19.06.13 12:09, Reshetova, Elena (elena.reshet...@intel.com) wrote:
This is the patch for review for enabling smack labelling for
device
nodes.
The functionality and reasoning is inside. I will be happy to
answer any questions.
So, this needs some HAVE_SMACK ifdeffery at least.
That said, I wonder if we should instead make this a generic
XATTR{foobar}=waldo thing. Kay?
Any update for this? if we use SMACK for udev, it requires it.
Lennart's suggestion seems more than reasonable - it would make it
generic
enough to do:
XATTR{security.SMACK64}=label
which I think is all we need here. Elena, do you need help respinning
this?
Sorry for the silence, it seems like I totally missed these replies
(got buried in my mailbox)!
Sure, I can make a change, but I am not exactly sure what you mean by
this:
XATTR{security.SMACK64}=label. Adding simple HAVE_SMACK ifdeffery
is easy, but the later part I didn't really understand.
Well, we just want this to be a bit more generic. i.e. we want a generic
XATTR{} concept for udev rules, so that you can set any kind of xattrs, not
just the ones SMACK needs. That way we can nicely handle the SMACK case, but
possibly also handle a lot of other cases where people just want to use
xattrs. Also the SMACK-specific ifdeffery then just becomes an
XATTR-specific ifdeffery...
Oh, now I understand and indeed makes a lot of sense. Thank you for
explaining!
If it is just longer to explain it to me, Auke, you can go ahead and
make a change and I will just learn from looking into it :)
Unfortunately, I don't know systemd code well enough.
Well, you did the initial patch, right? Changing this to be this tiny bit
mor expressive should be easy. But anyway, I'll let you an Auke figure this
out...
Actually the initial patch was done by Brian McGillion (as it says inside
the patch), I was mostly just rebasing it and changing some small things
since I inherited the patch maintenance. But sure, I will do the change
while flying back from my trip, since now I understand what needs to be
done.
Best Regards,
Elena
smime.p7s
Description: S/MIME cryptographic signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Patch for Smack labelling support in udev
On Tue, Jun 18, 2013 at 4:43 AM, Auke-jan H Kok auke-jan.h@intel.com
wrote:
On Mon, Jun 17, 2013 at 9:37 PM, Kyungmin Park kmp...@infradead.org wrote:
Hi Elena,
On Thu, Jun 6, 2013 at 7:10 PM, Lennart Poettering
lenn...@poettering.net wrote:
On Wed, 08.05.13 11:16, Reshetova, Elena (elena.reshet...@intel.com)
wrote:
Hi,
This is the patch for review for enabling smack labelling for device
nodes.
The functionality and reasoning is inside. I will be happy to answer
any questions.
So, this needs some HAVE_SMACK ifdeffery at least.
That said, I wonder if we should instead make this a generic
XATTR{foobar}=waldo thing. Kay?
Any update for this? if we use SMACK for udev, it requires it.
Lennart's suggestion seems more than reasonable - it would make it generic
enough to do:
XATTR{security.SMACK64}=label
which I think is all we need here. Elena, do you need help respinning this?
Sorry for the silence, it seems like I totally missed these replies (got
buried in my mailbox)!
Sure, I can make a change, but I am not exactly sure what you mean by this:
XATTR{security.SMACK64}=label. Adding simple HAVE_SMACK ifdeffery is
easy, but the later part I didn't really understand.
If it is just longer to explain it to me, Auke, you can go ahead and make a
change and I will just learn from looking into it :) Unfortunately, I don't
know systemd code well enough.
Best Regards,
Elena.
smime.p7s
Description: S/MIME cryptographic signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Patch for Smack labelling support in udev
Hi Elena,
On Thu, Jun 6, 2013 at 7:10 PM, Lennart Poettering
lenn...@poettering.net wrote:
On Wed, 08.05.13 11:16, Reshetova, Elena (elena.reshet...@intel.com) wrote:
Hi,
This is the patch for review for enabling smack labelling for device nodes.
The functionality and reasoning is inside. I will be happy to answer any
questions.
So, this needs some HAVE_SMACK ifdeffery at least.
That said, I wonder if we should instead make this a generic
XATTR{foobar}=waldo thing. Kay?
Any update for this? if we use SMACK for udev, it requires it.
Thank you,
Kyungmin Park
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Patch for Smack labelling support in udev
On Mon, Jun 17, 2013 at 9:37 PM, Kyungmin Park kmp...@infradead.org wrote:
Hi Elena,
On Thu, Jun 6, 2013 at 7:10 PM, Lennart Poettering
lenn...@poettering.net wrote:
On Wed, 08.05.13 11:16, Reshetova, Elena (elena.reshet...@intel.com) wrote:
Hi,
This is the patch for review for enabling smack labelling for device nodes.
The functionality and reasoning is inside. I will be happy to answer any
questions.
So, this needs some HAVE_SMACK ifdeffery at least.
That said, I wonder if we should instead make this a generic
XATTR{foobar}=waldo thing. Kay?
Any update for this? if we use SMACK for udev, it requires it.
Lennart's suggestion seems more than reasonable - it would make it
generic enough to do:
XATTR{security.SMACK64}=label
which I think is all we need here. Elena, do you need help respinning this?
Auke
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Patch for Smack labelling support in udev
Hi, This is the patch for review for enabling smack labelling for device nodes. The functionality and reasoning is inside. I will be happy to answer any questions. Best Regards, Elena. 0001-Adding-Smack-support-for-udev-nodes-labelling.patch Description: Binary data smime.p7s Description: S/MIME cryptographic signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Patch for Smack labelling support in udev
On Wed, 2013-05-08 at 11:16 +, Reshetova, Elena wrote: The functionality and reasoning is inside. I will be happy to answer any questions. Why is this different from how SELinux works? There from what I can see there's a centralized API to look up the expected label for a given filename (selabel_lookup_raw), and then set the target label for newly created files in the current thread (setfscreatecon). That way we're ensuring the file is created atomically with that label. So why is is SMACK different here, and could it fit into what already exists in src/shared/label.c ? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
